Messages in this thread |  | | Date | Wed, 26 Nov 2025 18:41:39 +0000 | | From | Mark Brown <> | | Subject | Re: [PATCH v8 11/29] KVM: arm64: Document the KVM ABI for SME |
| |
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 is > > > > + enabled 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 to > > > > + the guest on this vcpu, and determines which register slices are > > > > + visible through this ioctl interface. > > > > > > + If SME is supported then the max_vq used for the Z and P registers > > > > + while SVCR.SM is 1 this vector length will be the maximum SME > > > > + vector length available for the guest, otherwise it will be the > > > > + maximum 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. [unhandled content-type:application/pgp-signature] |  |