[PATCH 21/27] arm64/sve: KVM: Prevent guests from using SVE

[Dave Martin]

On Wed, Aug 16, 2017 at 12:20:41PM +0100, Marc Zyngier wrote:
> On 16/08/17 11:50, Dave Martin wrote:
> > On Tue, Aug 15, 2017 at 05:33:15PM +0100, Marc Zyngier wrote:
> >> On 09/08/17 13:05, Dave Martin wrote:
> >>> Until KVM has full SVE support, guests must not be allowed to
> >>> execute SVE instructions.
> >>>
> >>> This patch enables the necessary traps, and also ensures that the
> >>> traps are disabled again on exit from the guest so that the host
> >>> can still use SVE if it wants to.
> >>>
> >>> Signed-off-by: Dave Martin <Dave.Martin at arm.com>
> >>> ---
> >>>  arch/arm64/include/asm/kvm_arm.h | 3 ++-
> >>>  arch/arm64/kvm/hyp/switch.c      | 6 +++---
> >>>  2 files changed, 5 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> >>> index dbf0537..8a19651 100644
> >>> --- a/arch/arm64/include/asm/kvm_arm.h
> >>> +++ b/arch/arm64/include/asm/kvm_arm.h
> >>> @@ -186,7 +186,7 @@
> >>>  #define CPTR_EL2_TTA	(1 << 20)
> >>>  #define CPTR_EL2_TFP	(1 << CPTR_EL2_TFP_SHIFT)
> >>>  #define CPTR_EL2_TZ	(1 << 8)
> >>> -#define CPTR_EL2_DEFAULT	0x000033ff
> >>> +#define CPTR_EL2_DEFAULT	(0x000033ff & ~CPTR_EL2_TZ)
> >>
> >> I must say I'm not overly fond of this construct. I'd rather introduce a
> >> RES1 field that matches the v8.2 description, instead of this ugly
> >> constant and something that clears it.
> > 
> > Sorry, I don't get your meaning here.  v8.2 neither immediately predates
> > or postdates SVE.  
> 
> The ARMv8 ARM (DDI406B_a, D7.2.19) says otherwise. This bit is only
> defined as having a possibility of being 0 on an v8.2 implementation if
> SVE is implemented.

Right.  I was confused by the v8.2 reference, since if this weren't true
for v8.0 of the architecture, we couldn't simply change a compile time
constant here.  In fact, there's a compatible retroactive change to all
arch versions >= v8.0.

> > What are you propsing?
> 
> What I'm proposing is:
> 
> #define CPTR_EL2_RES1		0x32ff
> #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
> 
> and none of that pointless constant clearing.
> 
> > I guess we could just write 0x000032ff now that the only meaning the
> > architecture can ever assign to bit 8 is known.
> Exactly.

OK, good -- I'll change that.

I was trying to avoid magic numberness, but it's a bit futile when
talking about RESx bits.

Cheers
---Dave