[RFC PATCH 0/9] powerpc/mm: Restructure Linux PTE on Book3S/64 to radix format

This patch series modifies the Linux PTE format used on 64-bit Book3S processors (i.e. POWER server processors) to make the bits line up with the PTE format used in the radix trees defined in PowerISA v3.0. This will reduce the amount of further change required to make a kernel that can run with ei

[RFC PATCH 1/9] powerpc/mm/book3s-64: Clean up some obsolete or misleading comments

No code changes. Signed-off-by: Paul Mackerras --- arch/powerpc/include/asm/book3s/64/hash.h | 13 ++--- arch/powerpc/mm/hash64_64k.c | 3 +-- arch/powerpc/mm/hash_utils_64.c | 10 +- 3 files changed, 12 insertions(+), 14 deletions(-) diff --git a/arch/po

[RFC PATCH 2/9] powerpc/mm/book3s-64: Free up 7 high-order bits in the Linux PTE

This frees up bits 57-63 in the Linux PTE on 64-bit Book 3S machines. In the 4k page case, this is done just by reducing the size of the RPN field to 39 bits, giving 51-bit real addresses. In the 64k page case, we had 10 unused bits in the middle of the PTE, so this moves the RPN field down 10 bit

[RFC PATCH 3/9] powerpc/mm/64: Use physical addresses in upper page table tree levels

This changes the Linux page tables to store physical addresses rather than kernel virtual addresses in the upper levels of the tree (pgd, pud and pmd) for all 64-bit machines. This frees up some high order bits, and will be needed with book3s PowerISA v3.0 machines which read the page table tree i

[RFC PATCH 4/9] powerpc/mm/book3s-64: Move _PAGE_PRESENT to the most significant bit

This changes _PAGE_PRESENT for 64-bit Book 3S processors from 0x2 to 0x8000___, because that is where PowerISA v3.0 CPUs in radix mode will expect to find it. Signed-off-by: Paul Mackerras --- arch/powerpc/include/asm/book3s/64/hash-64k.h | 10 +- arch/powerpc/include/asm/boo

[RFC PATCH 5/9] powerpc/mm/book3s-64: Move _PAGE_PTE to 2nd most significant bit

This changes _PAGE_PTE for 64-bit Book 3S processors from 0x1 to 0x4000___, because that bit is used as the L (leaf) bit by PowerISA v3.0 CPUs in radix mode. The "leaf" bit indicates that the PTE points to a page directly rather than another radix level, which is what the _PAGE_PTE bit

[RFC PATCH 6/9] powerpc/mm/book3s-64: Move HPTE-related bits in PTE to upper end

This moves the _PAGE_HASHPTE, _PAGE_F_GIX and _PAGE_F_SECOND fields in the Linux PTE on 64-bit Book 3S systems to the most significant byte. Of the 5 bits, one is a software-use bit and the other four are reserved bit positions in the PowerISA v3.0 radix PTE format. Using these bits is OK because t

[RFC PATCH 7/9] powerpc/mm/book3s-64: Shuffle read, write, execute and user bits in PTE

This moves the _PAGE_EXEC, _PAGE_RW and _PAGE_USER bits around in the Linux PTE on 64-bit Book 3S systems to correspond with the bit positions used in radix mode by PowerISA v3.0 CPUs. This also adds a _PAGE_READ bit corresponding to the read permission bit in the radix PTE. _PAGE_READ is current

[RFC PATCH 8/9] powerpc/mm/book3s-64: Move software-used bits in PTE

This moves the _PAGE_BUSY, _PAGE_SPECIAL and _PAGE_SOFT_DIRTY bits in the Linux PTE on 64-bit Book 3S systems to bit positions which are designated for software use in the radix PTE format used by PowerISA v3.0 CPUs in radix mode. Signed-off-by: Paul Mackerras --- arch/powerpc/include/asm/book3s

[RFC PATCH 9/9] powerpc/mm/book3s-64: Expand the real page number field of the Linux PTE

Now that other PTE fields have been moved out of the way, we can expand the RPN field of the PTE on 64-bit Book 3S systems and align it with the RPN field in the radix PTE format used by PowerISA v3.0 CPUs in radix mode. For 64k page size, this means we need to move the _PAGE_COMBO and _PAGE_4K_PF

Re: [PATCH] spapr: Don't set the TM ibm,pa-features bit in PR KVM mode

On Mon, Apr 04, 2016 at 09:09:28PM +1000, Anton Blanchard wrote: > We don't support transactional memory in PR KVM, so don't tell > the OS that we do. This assumes PR KVM won't ever support TM, which is hopefully not true. If PR KVM does get TM support in future, then QEMU will have no clear way