Re: [RFC PATCH] kvmppc: protection keys fix

[Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>]

Ram Pai <linuxram@us.ibm.com> writes:

> On Wed, Aug 02, 2017 at 02:18:42PM +0530, Aneesh Kumar K.V wrote:
>> Ram Pai <linuxram@us.ibm.com> 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@us.ibm.com>
>> > ---
>> >  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