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

On Mon, 12 Jan 2026 at 13:27, Mark Brown [off-list ref] wrote:

On Fri, Jan 09, 2026 at 03:59:00PM +0000, Fuad Tabba wrote:

quoted

On Tue, 23 Dec 2025 at 01:22, Mark Brown [off-list ref] wrote:

quoted

quoted

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

quoted

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.

quoted

quoted

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

quoted

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.

I understand. My point is, by code inspection we can demonstrate that
this isn't needed.

Cheers,
/fuad