On Thu, Feb 06, 2025 at 07:12:52PM +0000, Mark Brown wrote:
> On Thu, Feb 06, 2025 at 02:11:02PM +0000, Mark Rutland wrote:
>
> > +static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
> > +{
> > + u64 zcr_el1, zcr_el2;
> > +
> > + if (!guest_owns_fp_regs())
> > + return;
> > +
> > + if (vcpu_has_sve(vcpu)) {
> > + /* A guest hypervisor may restrict the effective max VL. */
> > + if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu))
> > + zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
> > + else
> > + zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
> > +
> > + write_sysreg_el2(zcr_el2, SYS_ZCR);
> > +
> > + zcr_el1 = __vcpu_sys_reg(vcpu, vcpu_sve_zcr_elx(vcpu));
> > + write_sysreg_el1(zcr_el1, SYS_ZCR);
> > + }
> > +}
>
> I don't think we should worry about it for this series but just for
> future reference:
>
> These new functions do unconditional writes for EL2, the old code made
> use of sve_cond_update_zcr_vq() which suppresses the writes but didn't
> have the selection of actual sysreg that write_sysreg_el2() has. I
> believe this was done due to a concern about potential overheads from
> writes to the LEN value effective in the current EL. OTOH that also
> introduced an additional read to get the current value, and that was all
> done without practical systems to benchmark any actual impacts from noop
> writes so there's a reasonable chance it's just not a practical issue.
> We should check this on hardware, but that can be done separately.
Yep, I'm aware of that.
Mark.
