On Wed, Nov 26, 2025 at 05:23:47PM +0000, Dave Martin wrote:
On Mon, Nov 24, 2025 at 08:12:56PM +0000, Mark Brown wrote:
On Mon, Nov 24, 2025 at 03:48:06PM +0000, Peter Maydell wrote:
.. [1] These encodings are not accepted for SVE-enabled vcpus. See
:ref:`KVM_ARM_VCPU_INIT`.
:ref:`KVM_ARM_VCPU_INIT`. They are also not accepted when SME isenabled without SVE and the vcpu is in streaming mode.
Does this mean that on an SME-no-SVE VM the VMM needs to know if the vcpu is currently in streaming mode or not to determine whether to read the FP registers as fp_regs or sve regs? That seems unpleasant -- I was expecting this to be strictly a matter of how the VM was configured (as it is with SVE).
Yes, it does.
Is the above condition right re streaming mode? The original reason for this restriction was that the SVE Z-regs and FPSIMD V-regs are aliases when SVE is present. To avoid having to worry about how to order register accesses and/or paste parts of them together, we went down the road of banishing encodings that alias a subset of the register state accessed by some other encoding.
I queried the issue with requiring that writes to the registers be done in a specific order - we apparently have some other examples of this already (I would need to go and check which specifically) so that was seen as OK.
In line with this principle, with SME Vn and Zn are aliases when *not* in streaming mode, so allowing access through the Vn view feels problematic too? (And when in streaming mode, the Vn regs don't exist at all.)
The ABI proposed here is that the V registers will only be available with a VM that lacks SVE, you'll never have them both simultaneously but rather which is available at any given moment will vary on a SME without SVE VM. This obviously has complications, but aliasing is not one of them.
Another option would be to represent the V registers as 128 bit Z registers, giving you something similar to how they'd appear on a VM with both SVE and SME for a SME only VM.
Whether the proposed ABI is considered awkward for VMMs or not is a separate matter...)
Indeed.
max_vq. This is the maximum vector length currently available tothe guest on this vcpu, and determines which register slices arevisible through this ioctl interface.
If SME is supported then the max_vq used for the Z and P registerswhile SVCR.SM is 1 this vector length will be the maximum SMEvector length available for the guest, otherwise it will be themaximum SVE vector length available.
The max_vq name here is not ABI; it's just linking concepts together in the documentation text.
So, can we give explicitly different names to these two max_vq values?
We could call them sve_max_vq and sme_max_vq?
Splitting the affected register descriptions into "SVCR.SM == 0" and "SVCR.SM == 1" cases also be helpful to make this special-casing clear.
Possibly I'm looking at the wrong thing here but the overall text for describing the vector registers is relatively long so I worry that it'd be harder for readers to play spot the difference if there was duplication. I figured explicitly calling out the differences would be clearer and less error prone in terms of any future updates.
This is attempting to say that the VL for the Z and P registers (and FFR) will vary depending on if the vCPU is in streaming mode or not if the maximum VL for SVE and SME differs, similarly to how the Z, P and FFR registers disappear when we are not in streaming mode in a SME only system.
May flipping SVCR.SM through KVM_SET_ONE_REG have the architectural effect of zeroing the vector regs? That feels like something that should be stated explicitly.
Yes, it should zero them - I'll find some place/way to add that.
I'd agree that this mutating interface feels odd, and does not follow the original spirit of the design here.
But the SME architecture doesn't fit well with the spirit of the original KVM ABI here either, so I guess there won't be a perfect solution.
Something's going to be awkward somewhere.
It seems that when SME is enabled in the vCPU features and the VMM is planning to dump or set affected registers, there is a requirement to dump / set SVCR.SM first, and then go down one of two code paths. Can this be called out explicitly? This is a departure from the the previous interaction model, so it probably deserves its own section, which can then be cross-referenced from individual reg descriptions.
SVCR.SM exhibits this modality w.r.t a specific set of affected register encodings; it would be good to have that captured clearly in one place.
As I said above my understanding is that this is not actually a departure from the current stituation, this not being noticed probably highlights why it'd be good to improve the documentation here! I think grouping all behaviours like this together would be good from a usability point of view. I don't know how much of that that fits directly in the ABI document or in a separate "here's some gotchas" type document, things are already getting a bit difficult to manage. Possibly both.