On Fri, Feb 14, 2025 at 09:24:03AM +0000, Marc Zyngier wrote: > Mark Brown <broo...@kernel.org> wrote:
> Just to be clear: I do not intend to review a series that doesn't
> cover the full gamut of KVM from day 1. Protected mode is an absolute
> requirement. It is the largest KVM deployment, and Android phones the
> only commonly available platform with SME. If CCA gets merged prior to
> SME support, supporting it will also be a requirement.
OK, no problem. This is a new requirement and I'd been trying to
balance the concerns people have with the size of serieses like this
with the need to get everything in, my plan had been to follow up as
soon as possible with pKVM.
> > Access to the floating point registers follows the architecture:
> > - When both SVE and SME are present:
> > - If PSTATE.SM == 0 the vector length used for the Z and P registers
> > is the SVE vector length.
> > - If PSTATE.SM == 1 the vector length used for the Z and P registers
> > is the SME vector length.
> > - If only SME is present:
> > - If PSTATE.SM == 0 the Z and P registers are inaccessible and the
> > floating point state accessed via the encodings for the V registers.
> > - If PSTATE.SM == 1 the vector length used for the Z and P registers
> > - The SME specific ZA and ZT0 registers are only accessible if SVCR.ZA is
> > 1.
> > The VMM must understand this, in particular when loading state SVCR
> > should be configured before other state.
> Why SVCR? This isn't a register, just an architected accessor to
> PSTATE.{ZA,SM}. Userspace already has direct access to PSTATE, so I
> don't understand this requirement.
Could you be more explicit as to what you mean by direct access to
PSTATE here? The direct access to these PSTATE fields is in the form of
SVCR register accesses, or writes via SMSTART or SMSTOP instructions
when executing code - is there another access mechanism I'm not aware of
here? They don't appear in SPSR. Or is this a terminology issue with
referring to SVCR as the mechanism for configuring PSTATE.{SM,ZA}
without explicitly calling out that that's what's happening?
> Isn't it that there is simply a dependency between restoring PSTATE
> and any of the vector stuff? Also, how do you preserve the current ABI
> that do not have this requirement?
Yes, that's the dependency - I'm spelling out explicitly what changes in
the register view when PSTATE.{SM,ZA} are restored. This ABI is what
you appeared to be asking for the last time we discussed this.
Previously I had also proposed either:
- Exposing the streaming mode view of the register state as separate
registers, selecting between the standard and streaming views for
load/save based on the mode when the guest runs and clearing the
inactive registers on userspace access.
- Always presenting userspace with the largest available vector length,
zero padding when userspace reads and discarding unused high bits
when loading into the registers for the guest. This ends up
requiring rewriting between VLs, or to/from FPSIMD format, around
periods of userspace access since when normally executing and context
switching the guest we want to store the data in the native format
for the current PSTATE.SM for performance.
both of which largely avoid the ordering requirements but add complexity
to the implementation, and memory overhead in the first case. I'd
originally implemented the second case, that seems the best of the
available options to me. You weren't happy with these options and said
that we should not translate register formats and always use the current
mode for the vCPU, but given that changing PSTATE.SM changes the
register sizes that ends up creating an ordering requirement. You
seemed to agree that it was reasonable to have an ordering requirement
with PSTATE.SM so long as it only came when SME had been explicitly
enabled.
Would you prefer:
- Changing the register view based on the current value of PSTATE.SM.
- Exposing streaming mode Z and P as separate registers.
- Exposing the existing Z and P registers with the maximum S?E VL.
or some other option?
signature.asc
Description: PGP signature
