[PATCH v9 14/30] KVM: arm64: Implement SME vector length configuration

[Mark Brown]

On Fri, Jan 09, 2026 at 03:59:00PM +0000, Fuad Tabba wrote:
> On Tue, 23 Dec 2025 at 01:22, Mark Brown <broonie at kernel.org> wrote:

> > +
> > +#define vcpu_cur_sve_vl(vcpu) (vcpu_in_streaming_mode(vcpu) ? \
> > +                              vcpu_sme_max_vl(vcpu) : vcpu_sve_max_vl(vcpu))

> nit: This isn't really the current VL, but the current max VL. That
> said, I don't think 'cur_max` is a better name. Maybe a comment or
> something?

It is the current VL for the hypervisor and what we present to
userspace, EL1 can reduce the VL that it sees to something lower if the
hardware supports that but as far as the hypervisor is concerned the VL
is always whatever is configured at EL2.  We can obviously infer what
the guest is doing internally but we never really interact with it.  The
existing code doesn't really have a concept of current VL since with SVE
only the hypervisor set VL is always the SVE VL, it often refers to the
maximum VL when it means the VL the hypervisor works with.

> > +       if (WARN_ON(vcpu->arch.sve_state || vcpu->arch.sme_state))
> > +               return -EINVAL;
> > +

> Can this ever happen? kvm_arm_vcpu_vec_finalized() is checked above,
> and vcpu->arch.{sve,sme}_state are only assigned in
> kvm_vcpu_finalize_vec() immediately before setting the finalized flag.

I don't expect it to, hence why it's a WARN_ON.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260112/ffa473f9/attachment.sig>