On Thu, Nov 27, 2025 at 03:06:50PM +0000, Peter Maydell wrote:
On Mon, 24 Nov 2025 at 20:13, Mark Brown broonie@kernel.org wrote:
That was deliberate and I agree it is awkward, it was introduced as a result of earlier review comments. I had originally implemented an ABI where the VL for the vector registers was the maximum of the SVE and SME VLs but the feedback was that the ABI should instead follow what the architecture does with the vector length and potentially presence of the vector registers depending on the current streaming mode configuration. It sounds like you would prefer something more like what was there originally?
Yes, that's what I would prefer. The "varies by current CPU state" approach seems to me to be not the way we do things right now, and to be awkward for the VMM side, so it ought to have a really strong justification for why we need it.
Generally the VMM doesn't care about the actual current state of the CPU, it just wants all the data (e.g. to send for migration). We don't make the current SVE accessors change based on what the current SVE vq length is or whether the guest has set the SVE enable bits -- we have "if the vcpu supports SVE at all, data is always accessed via the SVE accessors, and it's always the max_vq length, regardless of how the vcpu has set its current vq length".
OK, that's clear - that was my expectation for what userspace would want too FWIW.
What's the benefit of making the way KVM exposes the data bounce around based on the current CPU state? Does that make things easier for the kernel internally?
Yes, it makes life easier for the kernel internally. If we expose the registers to userspace with a potentially non-native format then we need to keep track of the format things are currently stored in and rewrite the data between the format we're exposing and the format we're going to load/save to/from the hardware when those differ. It's not an issue in the normal fast path for running guests, it's only a concern when userspace actually interacts with the affected registers.
This won't have come up in the SVE case since what's exposed is the hypervisor view of the registers which doesn't change based on what the guest does so you just need a bit of configuration of ZCR_ELx.LEN, with SME the current value of PSTATE.SM changes the view of the registers for all ELs.