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

[Fuad Tabba]

Hi Marc,

On Mon, May 20, 2024 at 9:05 AM Marc Zyngier <maz at kernel.org> wrote:
>
> 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:

Will do.

Cheers,
/fuad


>
> - 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.