linux.git/include/asm-powerpc/pgtable-ppc64.h, branch master

powerpc: Move include files to arch/powerpc/include/asm

2008-08-04T02:02:00+00:00

from include/asm-powerpc.  This is the result of a

mkdir arch/powerpc/include/asm
git mv include/asm-powerpc/* arch/powerpc/include/asm

Followed by a few documentation/comment fixups and a couple of places
where  was being used explicitly.  Of the latter only
one was outside the arch code and it is a driver only built for powerpc.

Signed-off-by: Stephen Rothwell 
Signed-off-by: Paul Mackerras

powerpc/mm: Lockless get_user_pages_fast() for 64-bit (v3)

2008-07-30T05:26:54+00:00

Implement lockless get_user_pages_fast for 64-bit powerpc.

Page table existence is guaranteed with RCU, and speculative page references
are used to take a reference to the pages without having a prior existence
guarantee on them.

Signed-off-by: Nick Piggin 
Signed-off-by: Dave Kleikamp 
Signed-off-by: Andrew Morton 
Signed-off-by: Benjamin Herrenschmidt

powerpc/mm: Implement _PAGE_SPECIAL & pte_special() for 64-bit

2008-07-28T06:30:52+00:00

Implement _PAGE_SPECIAL and pte_special() for 64-bit powerpc. This bit will
be used by the fast get_user_pages() to differenciate PTEs that correspond
to a valid struct page from special mappings that don't such as IO mappings
obtained via io_remap_pfn_ranges().

Signed-off-by: Nick Piggin 
Acked-by: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Hugh Dickins 
Cc: "Paul E. McKenney" 
Reviewed-by: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Benjamin Herrenschmidt

powerpc ioremap_prot

2008-07-24T17:47:15+00:00

This adds ioremap_prot and pte_pgprot() so that one can extract protection
bits from a PTE and use them to ioremap_prot() (in order to support ptrace
of VM_IO | VM_PFNMAP as per Rik's patch).

This moves a couple of flag checks around in the ioremap implementations
of arch/powerpc.  There's a side effect of allowing non-cacheable and
non-guarded mappings on ppc32 which before would always have _PAGE_GUARDED
set whenever _PAGE_NO_CACHE is.

(standard ioremap will still set _PAGE_GUARDED, but ioremap_prot will be
capable of setting such a non guarded mapping).

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Rik van Riel 
Cc: Dave Airlie 
Cc: Hugh Dickins 
Cc: Paul Mackerras 
Cc: Arnd Bergmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge commit 'origin/HEAD' into test-merge

2008-07-14T04:29:49+00:00

Manual fixup of include/asm-powerpc/pgtable-ppc64.h

powerpc/mm: Define flags for Strong Access Ordering

2008-07-09T06:30:45+00:00

This patch defines:

- PROT_SAO, which is passed into mmap() and mprotect() in the prot field
- VM_SAO in vma->vm_flags, and
- _PAGE_SAO, the combination of WIMG bits in the pte that enables strong
access ordering for the page.

Signed-off-by: Dave Kleikamp 
Signed-off-by: Benjamin Herrenschmidt

Correct hash flushing from huge_ptep_set_wrprotect()

2008-07-08T16:27:58+00:00

As Andy Whitcroft recently pointed out, the current powerpc version of
huge_ptep_set_wrprotect() has a bug.  It just calls ptep_set_wrprotect()
which in turn calls pte_update() then hpte_need_flush() with the 'huge'
argument set to 0.  This will cause hpte_need_flush() to flush the wrong
hash entries (of any).  Andy's fix for this is already in the powerpc
tree as commit 016b33c4958681c24056abed8ec95844a0da80a3.

I have confirmed this is a real bug, not masked by some other
synchronization, with a new testcase for libhugetlbfs.  A process write
a (MAP_PRIVATE) hugepage mapping, fork(), then alter the mapping and
have the child incorrectly see the second write.

Therefore, this should be fixed for 2.6.26, and for the stable tree.
Here is a suitable patch for 2.6.26, which I think will also be suitable
for the stable tree (neither of the headers in question has been changed
much recently).

It is cut down slighlty from Andy's original version, in that it does
not include a 32-bit version of huge_ptep_set_wrprotect().  Currently,
hugepages are not supported on any 32-bit powerpc platform.  When they
are, a suitable 32-bit version can be added - the only 32-bit hardware
which supports hugepages does not use the conventional hashtable MMU and
so will have different needs anyway.

Signed-off-by: Andy Whitcroft 
Signed-off-by: David Gibson 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Linus Torvalds

powerpc: Add 64 bit version of huge_ptep_set_wrprotect

2008-07-01T01:28:56+00:00

The implementation of huge_ptep_set_wrprotect() directly calls
ptep_set_wrprotect() to mark a hugepte write protected.  However this
call is not appropriate on ppc64 kernels as this is a small page only
implementation.  This can lead to the hash not being flushed correctly
when a mapping is being converted to COW, allowing processes to continue
using the original copy.

Currently huge_ptep_set_wrprotect() unconditionally calls
ptep_set_wrprotect().  This is fine on ppc32 kernels as this call is
generic.  On 64 bit this is implemented as:

	pte_update(mm, addr, ptep, _PAGE_RW, 0);

On ppc64 this last parameter is the page size and is passed directly on
to hpte_need_flush():

	hpte_need_flush(mm, addr, ptep, old, huge);

And this directly affects the page size we pass to flush_hash_page():

	flush_hash_page(vaddr, rpte, psize, ssize, 0);

As this changes the way the hash is calculated we will flush the wrong
pages, potentially leaving live hashes to the original page.

Move the definition of huge_ptep_set_wrprotect() to the 32/64 bit specific
headers.

Signed-off-by: Andy Whitcroft 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras

powerpc: Free a PTE bit on ppc64 with 64K pages

2008-06-30T12:30:53+00:00

This frees a PTE bit when using 64K pages on ppc64.  This is done
by getting rid of the separate _PAGE_HASHPTE bit.  Instead, we just test
if any of the 16 sub-page bits is set.  For non-combo pages (ie. real
64K pages), we set SUB0 and the location encoding in that field.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras

[POWERPC] vmemmap fixes to use smaller pages

2008-05-15T10:49:25+00:00

This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.

The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.

In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.

The logic used by my match to choose the vmemmap page size is:

 - If 16M pages are available and there's 1G or more RAM at boot,
   use that size.
 - Else if 64K pages are available, use that
 - Else use 4K pages

I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.

Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.

Signed-off-by: Paul Mackerras