On Fri, Jan 09, 2026 at 03:59:00PM +0000, Fuad Tabba wrote:
On Tue, 23 Dec 2025 at 01:22, Mark Brown broonie@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.