[PATCH v1 6/7] KVM: arm64: Eagerly restore host fpsimd/sve state in pKVM

Marc Zyngier maz at kernel.org
Mon May 20 01:05:34 PDT 2024


On Mon, 20 May 2024 08:37:22 +0100,
Fuad Tabba <tabba at google.com> wrote:
> 
> Hi Oliver,
> 
> On Fri, May 17, 2024 at 6:09 PM Oliver Upton <oliver.upton at linux.dev> wrote:
> >
> > Hi Fuad,
> >
> > On Fri, May 17, 2024 at 02:18:13PM +0100, Fuad Tabba wrote:
> > >  static void kvm_hyp_save_fpsimd_host(struct kvm_vcpu *vcpu)
> > >  {
> > > -     __fpsimd_save_state(*host_data_ptr(fpsimd_state));
> > > +     /*
> > > +      * Non-protected kvm relies on the host restoring its sve state.
> > > +      * Protected kvm restores the host's sve state as not to reveal that
> > > +      * fpsimd was used by a guest nor leak upper sve bits.
> > > +      */
> > > +     if (unlikely(is_protected_kvm_enabled() && system_supports_sve())) {
> > > +             __hyp_sve_save_host();
> > > +
> > > +             /* Re-enable SVE traps for guests that do not support it. */
> > > +             if (!vcpu_has_sve(vcpu))
> > > +                     sysreg_clear_set(cptr_el2, 0, CPTR_EL2_TZ);
> >
> > This doesn't account for hVHE. I wonder we'd be better off abstracting
> > CPTR_EL2 behind a helper wherever it gets used in nVHE and translate
> > into the VHE-format behind the scenes:
> 
> Right! Too many modes to keep track of :)
> 
> Abstracting cptr_el2 would make things clearer and less error-prone.
> I'll do that on the respin.

If we're going with the conversion game, then I'd suggest you use the
VHE format as the reference, and convert it to nVHE on the flight.
That's for a few reasons:

- like it or not, nVHE is going the way of the dodo. I love my v8.0
  hardware to bits, but it sucks, and nVHE is now optional anyway.

- Keeping everything in the VHE format helps drawing a parallel with
  what is happening in the kernel (you grep for the same symbols).

- One day, I hope to be able to rip any form of SVE/SME support out of
  nVHE and only keep it for hVHE, because there is no ARMv8.0
  implementations with these extensions (apart from SW models).  One
  day...

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list