Ram Pai <linuxram@xxxxxxxxxx> writes: > On Wed, Aug 02, 2017 at 02:18:42PM +0530, Aneesh Kumar K.V wrote: >> Ram Pai <linuxram@xxxxxxxxxx> writes: >> >> > kvmppc_do_h_enter() hcall, clobbers the high-order two bits of >> > the protection key in the lower pte (ptel). Hence >> > any pkey number above 7 fails to behave. >> > >> > The following patch, preserves the pkey bits. >> > >> > Signed-off-by: Ram Pai <linuxram@xxxxxxxxxx> >> > --- >> > arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 + >> > arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +- >> > 2 files changed, 2 insertions(+), 1 deletions(-) >> > >> > diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> > index 369f9ff..f07a1c0 100644 >> > --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> > +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> > @@ -109,6 +109,7 @@ >> > #define HPTE_R_KEY_BIT2 ASM_CONST(0x0000000000000800) >> > #define HPTE_R_KEY_BIT3 ASM_CONST(0x0000000000000400) >> > #define HPTE_R_KEY_BIT4 ASM_CONST(0x0000000000000200) >> > +#define HPTE_R_KEY (HPTE_R_KEY_LO | HPTE_R_KEY_HI) >> > >> > #define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000) >> > #define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff000000) >> > diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c >> > index ce6f212..d9462ab 100644 >> > --- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c >> > +++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c >> > @@ -268,7 +268,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags, >> > if (!realmode) >> > local_irq_restore(irq_flags); >> > >> > - ptel &= ~(HPTE_R_PP0 - psize); >> > + ptel &= HPTE_R_KEY | HPTE_R_PP0 | (psize-1); >> >> Is this all needed to get keys to work on kvm ? We use key value 31 and >> key value 0 along with absent and invalid hpte config to indicate mmio >> and host swapped pages ? Won't that need to be fixed ? > > The OS assumes key 0 and 1 are reserved and hence does not let > applications use it. And the device tree tells us if key 31 is used or > not. If it is used the OS does not let application use it either. > > Now, the device tree for KVM guests do not expose the key property yet. > That needs to be fixed. I'm currently preparing a patch for that. One question: did I understand correctly that Paul Mackerras' answer on this thread¹ means that KVM doesn't need to reserve any keys for itself and can pass on 32 keys to the guest? -- Thiago Jung Bauermann IBM Linux Technology Center ¹ https://www.spinics.net/lists/kvm-ppc/msg12765.html -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
