On Mon, Feb 17, 2025 at 09:37:26AM +0000, Marc Zyngier wrote: > Mark Brown <broo...@kernel.org> wrote: > > On Fri, Feb 14, 2025 at 09:24:03AM +0000, Marc Zyngier wrote:
> > > 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
> I'm painfully aware of the architecture limitations.
> However, I don't get your mention of SPSR here. The architecture is
> quite clear that PSTATE is where these bits are held, that they are
> not propagated anywhere else, and that's where userspace should expect
> to find them.
> The fact that SW must use SVCR to alter PSTATE.{ZA,SM} doesn't matter.
> We save/restore registers, not accessors. If this means we need to
> play a dance when the VMM accesses PSTATE to reconciliate KVM's
> internal view with the userspace view, so be it.
Could you please clarify what you're referring to as the VMM accessing
PSTATE here? The KVM API documentation defines it's concept of PSTATE
as:
0x6030 0000 0010 0042 PSTATE 64 regs.pstate
in api.rst but does not futher elaborate. Looking at the code the
values that appear there seem to be mapped fairly directly to SPSR
values, this is why I was talking about them above.
It's not clear to me that PSTATE in the architecture is a register
exactly. DDI0487 L.a D1.4 defines the PSTATE bits as being stored in a
ProcState pseudocode structure (ProcState is defined in J1.3.3.457, the
pseudocode maps PSTATE in J1.3.3.454) but has an explicit comment that
"There is no significace in the field order". I can't seem to locate an
architectural definition of the layout of PSTATE as a whole. I also
can't find any direct observability of PSTATE as a whole which would
require a layout definition for PSTATE itself from the architecture.
There *is* a statement in R_DQXFW that "The contents of PSTATE
immediately before the exception was taken are written to SPSR_ELx"
which is somewhat in conflict with the absence of SM and ZA fields in
any of SPSR_ELx. There's also R_BWCFK similarly for exception return,
though that also already has some additional text for PSTATE.{IT,T} for
returns to AArch32. If everything in PSTATE ends up getting written to
SPSR then we can use SPSR as our representation of PSTATE.
> It probably means you need to obtain a clarification of the
> architecture to define *where* these bits are stored in PSTATE,
> because that's not currently defined.
I will raise the issue with R_DQXFW and friends with the architects but
I'm not convinced that at this point the clarification wouldn't be an
adjustment to those rules rather than the addition of fields for SM and
ZA in the SPSRs. Without any additions the only access we have is via
SVCR.
> > > 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.
...
> > 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?
> My take on this hasn't changed. I want to see something that behaves
> *exactly* like the architecture defines the expected behaviour of a
> CPU.
> But you still haven't answered my question: How is the *current* ABI
> preserved? Does it require *not* selecting SME? Does it require
> anything else? I'm expecting simple answers to simple questions, not a
Yes, it requires not selecting SME and only that. If the VMM does not
enable SME then it should see no change.
> wall of text describing something that is not emulating the
> architecture.
I'm not clear what you're referring to as not emulating the architecture
here, I *think* it's the issues with PSTATE.{SM,ZA} not appearing in
SPSR_ELx and hence KVM's pstate?
Your general style of interaction means that it is not always altogether
clear when your intent is to just ask a simple question or when it is to
point out some problem you have seen.
signature.asc
Description: PGP signature
