2005-12-16 16:43:46 -05:00
|
|
|
#ifndef _ASM_POWERPC_PGTABLE_64K_H
|
|
|
|
|
#define _ASM_POWERPC_PGTABLE_64K_H
|
|
|
|
|
|
2005-11-06 19:06:55 -05:00
|
|
|
#include <asm-generic/pgtable-nopud.h>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#define PTE_INDEX_SIZE 12
|
|
|
|
|
#define PMD_INDEX_SIZE 12
|
|
|
|
|
#define PUD_INDEX_SIZE 0
|
|
|
|
|
#define PGD_INDEX_SIZE 4
|
|
|
|
|
|
2007-09-18 03:22:59 -04:00
|
|
|
#ifndef __ASSEMBLY__
|
2005-11-06 19:06:55 -05:00
|
|
|
#define PTE_TABLE_SIZE (sizeof(real_pte_t) << PTE_INDEX_SIZE)
|
|
|
|
|
#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
|
|
|
|
|
#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
|
|
|
|
|
|
|
|
|
|
#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
|
|
|
|
|
#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
|
|
|
|
|
#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
|
|
|
|
|
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-23 16:35:13 -05:00
|
|
|
#ifdef CONFIG_PPC_SUBPAGE_PROT
|
|
|
|
|
/*
|
|
|
|
|
* For the sub-page protection option, we extend the PGD with one of
|
|
|
|
|
* these. Basically we have a 3-level tree, with the top level being
|
|
|
|
|
* the protptrs array. To optimize speed and memory consumption when
|
|
|
|
|
* only addresses < 4GB are being protected, pointers to the first
|
|
|
|
|
* four pages of sub-page protection words are stored in the low_prot
|
|
|
|
|
* array.
|
|
|
|
|
* Each page of sub-page protection words protects 1GB (4 bytes
|
|
|
|
|
* protects 64k). For the 3-level tree, each page of pointers then
|
|
|
|
|
* protects 8TB.
|
|
|
|
|
*/
|
|
|
|
|
struct subpage_prot_table {
|
|
|
|
|
unsigned long maxaddr; /* only addresses < this are protected */
|
|
|
|
|
unsigned int **protptrs[2];
|
|
|
|
|
unsigned int *low_prot[4];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#undef PGD_TABLE_SIZE
|
|
|
|
|
#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
|
|
|
|
|
sizeof(struct subpage_prot_table))
|
|
|
|
|
|
|
|
|
|
#define SBP_L1_BITS (PAGE_SHIFT - 2)
|
|
|
|
|
#define SBP_L2_BITS (PAGE_SHIFT - 3)
|
|
|
|
|
#define SBP_L1_COUNT (1 << SBP_L1_BITS)
|
|
|
|
|
#define SBP_L2_COUNT (1 << SBP_L2_BITS)
|
|
|
|
|
#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
|
|
|
|
|
#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
|
|
|
|
|
|
|
|
|
|
extern void subpage_prot_free(pgd_t *pgd);
|
|
|
|
|
|
|
|
|
|
static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd)
|
|
|
|
|
{
|
|
|
|
|
return (struct subpage_prot_table *)(pgd + PTRS_PER_PGD);
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_PPC_SUBPAGE_PROT */
|
|
|
|
|
#endif /* __ASSEMBLY__ */
|
|
|
|
|
|
[PATCH] ppc64: Fix bug in SLB miss handler for hugepages
This patch, however, should be applied on top of the 64k-page-size patch to
fix some problems with hugepage (some pre-existing, another introduced by
this patch).
The patch fixes a bug in the SLB miss handler for hugepages on ppc64
introduced by the dynamic hugepage patch (commit id
c594adad5653491813959277fb87a2fef54c4e05) due to a misunderstanding of the
srd instruction's behaviour (mea culpa). The problem arises when a 64-bit
process maps some hugepages in the low 4GB of the address space (unusual).
In this case, as well as the 256M segment in question being marked for
hugepages, other segments at 32G intervals will be incorrectly marked for
hugepages.
In the process, this patch tweaks the semantics of the hugepage bitmaps to
be more sensible. Previously, an address below 4G was marked for hugepages
if the appropriate segment bit in the "low areas" bitmask was set *or* if
the low bit in the "high areas" bitmap was set (which would mark all
addresses below 1TB for hugepage). With this patch, any given address is
governed by a single bitmap. Addresses below 4GB are marked for hugepage
if and only if their bit is set in the "low areas" bitmap (256M
granularity). Addresses between 4GB and 1TB are marked for hugepage iff
the low bit in the "high areas" bitmap is set. Higher addresses are marked
for hugepage iff their bit in the "high areas" bitmap is set (1TB
granularity).
To avoid conflicts, this patch must be applied on top of BenH's pending
patch for 64k base page size [0]. As such, this patch also addresses a
hugepage problem introduced by that patch. That patch allows hugepages of
1MB in size on hardware which supports it, however, that won't work when
using 4k pages (4 level pagetable), because in that case hugepage PTEs are
stored at the PMD level, and each PMD entry maps 2MB. This patch simply
disallows hugepages in that case (we can do something cleverer to re-enable
them some other day).
Built, booted, and a handful of hugepage related tests passed on POWER5
LPAR (both ARCH=powerpc and ARCH=ppc64).
[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 03:57:52 -05:00
|
|
|
/* With 4k base page size, hugepage PTEs go at the PMD level */
|
|
|
|
|
#define MIN_HUGEPTE_SHIFT PAGE_SHIFT
|
|
|
|
|
|
2005-11-06 19:06:55 -05:00
|
|
|
/* PMD_SHIFT determines what a second-level page table entry can map */
|
|
|
|
|
#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
|
|
|
|
|
#define PMD_SIZE (1UL << PMD_SHIFT)
|
|
|
|
|
#define PMD_MASK (~(PMD_SIZE-1))
|
|
|
|
|
|
|
|
|
|
/* PGDIR_SHIFT determines what a third-level page table entry can map */
|
|
|
|
|
#define PGDIR_SHIFT (PMD_SHIFT + PMD_INDEX_SIZE)
|
|
|
|
|
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
|
|
|
|
|
#define PGDIR_MASK (~(PGDIR_SIZE-1))
|
|
|
|
|
|
|
|
|
|
/* Additional PTE bits (don't change without checking asm in hash_low.S) */
|
|
|
|
|
#define _PAGE_HPTE_SUB 0x0ffff000 /* combo only: sub pages HPTE bits */
|
|
|
|
|
#define _PAGE_HPTE_SUB0 0x08000000 /* combo only: first sub page */
|
|
|
|
|
#define _PAGE_COMBO 0x10000000 /* this is a combo 4k page */
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 07:24:02 -04:00
|
|
|
#define _PAGE_4K_PFN 0x20000000 /* PFN is for a single 4k page */
|
2007-05-08 02:27:28 -04:00
|
|
|
|
|
|
|
|
/* Note the full page bits must be in the same location as for normal
|
|
|
|
|
* 4k pages as the same asssembly will be used to insert 64K pages
|
|
|
|
|
* wether the kernel has CONFIG_PPC_64K_PAGES or not
|
|
|
|
|
*/
|
2005-11-06 19:06:55 -05:00
|
|
|
#define _PAGE_F_SECOND 0x00008000 /* full page: hidx bits */
|
|
|
|
|
#define _PAGE_F_GIX 0x00007000 /* full page: hidx bits */
|
|
|
|
|
|
|
|
|
|
/* PTE flags to conserve for HPTE identification */
|
|
|
|
|
#define _PAGE_HPTEFLAGS (_PAGE_BUSY | _PAGE_HASHPTE | _PAGE_HPTE_SUB |\
|
|
|
|
|
_PAGE_COMBO)
|
|
|
|
|
|
|
|
|
|
/* Shift to put page number into pte.
|
|
|
|
|
*
|
2007-08-03 00:08:24 -04:00
|
|
|
* That gives us a max RPN of 34 bits, which means a max of 50 bits
|
|
|
|
|
* of addressable physical space, or 46 bits for the special 4k PFNs.
|
2005-11-06 19:06:55 -05:00
|
|
|
*/
|
2007-08-03 00:08:24 -04:00
|
|
|
#define PTE_RPN_SHIFT (30)
|
2005-11-06 19:06:55 -05:00
|
|
|
#define PTE_RPN_MAX (1UL << (64 - PTE_RPN_SHIFT))
|
|
|
|
|
#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
|
|
|
|
|
|
|
|
|
|
/* _PAGE_CHG_MASK masks of bits that are to be preserved accross
|
|
|
|
|
* pgprot changes
|
|
|
|
|
*/
|
|
|
|
|
#define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
|
|
|
|
|
_PAGE_ACCESSED)
|
|
|
|
|
|
|
|
|
|
/* Bits to mask out from a PMD to get to the PTE page */
|
|
|
|
|
#define PMD_MASKED_BITS 0x1ff
|
|
|
|
|
/* Bits to mask out from a PGD/PUD to get to the PMD page */
|
|
|
|
|
#define PUD_MASKED_BITS 0x1ff
|
|
|
|
|
|
|
|
|
|
/* Manipulate "rpte" values */
|
|
|
|
|
#define __real_pte(e,p) ((real_pte_t) { \
|
|
|
|
|
(e), pte_val(*((p) + PTRS_PER_PTE)) })
|
|
|
|
|
#define __rpte_to_hidx(r,index) ((pte_val((r).pte) & _PAGE_COMBO) ? \
|
|
|
|
|
(((r).hidx >> ((index)<<2)) & 0xf) : ((pte_val((r).pte) >> 12) & 0xf))
|
|
|
|
|
#define __rpte_to_pte(r) ((r).pte)
|
|
|
|
|
#define __rpte_sub_valid(rpte, index) \
|
|
|
|
|
(pte_val(rpte.pte) & (_PAGE_HPTE_SUB0 >> (index)))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Trick: we set __end to va + 64k, which happens works for
|
|
|
|
|
* a 16M page as well as we want only one iteration
|
|
|
|
|
*/
|
|
|
|
|
#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
|
|
|
|
|
do { \
|
|
|
|
|
unsigned long __end = va + PAGE_SIZE; \
|
|
|
|
|
unsigned __split = (psize == MMU_PAGE_4K || \
|
|
|
|
|
psize == MMU_PAGE_64K_AP); \
|
|
|
|
|
shift = mmu_psize_defs[psize].shift; \
|
|
|
|
|
for (index = 0; va < __end; index++, va += (1 << shift)) { \
|
|
|
|
|
if (!__split || __rpte_sub_valid(rpte, index)) do { \
|
|
|
|
|
|
|
|
|
|
#define pte_iterate_hashed_end() } while(0); } } while(0)
|
|
|
|
|
|
2007-05-08 02:27:28 -04:00
|
|
|
#define pte_pagesize_index(mm, addr, pte) \
|
2006-06-14 20:45:18 -04:00
|
|
|
(((pte) & _PAGE_COMBO)? MMU_PAGE_4K: MMU_PAGE_64K)
|
2005-11-06 19:06:55 -05:00
|
|
|
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 07:24:02 -04:00
|
|
|
#define remap_4k_pfn(vma, addr, pfn, prot) \
|
|
|
|
|
remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
|
|
|
|
|
__pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
|
|
|
|
|
|
2005-12-16 16:43:46 -05:00
|
|
|
#endif /* _ASM_POWERPC_PGTABLE_64K_H */
|
