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.
Attachment:
signature.asc
Description: PGP signature
