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.
signature.asc
Description: PGP signature
