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@xxxxxxx> > >>> --- > >>> 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
