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

[Oliver Upton]

On Mon, May 20, 2024 at 09:05:34AM +0100, Marc Zyngier 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:

Agreed, I was thinking of hVHE as this 'thing on the side', but really
it is the direction of the architecture :) So yeah, prefer your
suggestion.

-- 
Thanks,
Oliver