Re: [PATCH v8 11/29] KVM: arm64: Document the KVM ABI for SME

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 5497 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]