[PATCH 5/5] KVM: arm64: Handle AArch32 SPSR_{irq,abt,und,fiq} as RAZ/WI

[Marc Zyngier]

On Wed, 25 Oct 2023 00:04:27 +0100,
Oliver Upton <oliver.upton at linux.dev> wrote:
> 
> On Tue, Oct 24, 2023 at 10:41:57PM +0000, Oliver Upton wrote:
> > On Tue, Oct 24, 2023 at 06:25:33PM +0100, Marc Zyngier wrote:
> > > On Mon, 23 Oct 2023 19:55:10 +0100, Miguel Luis <miguel.luis at oracle.com> wrote:
> > > > Also, could you please explain what is happening at PSTATE.EL == EL1
> > > > and if EL2Enabled() && HCR_EL2.NV == ‘1’  ?
> > > 
> > > We directly take the trap and not forward it. This isn't exactly the
> > > letter of the architecture, but at the same time, treating these
> > > registers as RAZ/WI is the only valid implementation. I don't
> > > immediately see a problem with taking this shortcut.
> > 
> > Ugh, that's annoying. The other EL2 views of AArch32 state UNDEF if EL1
> > doesn't implement AArch32. It'd be nice to get a relaxation in the
> > architecture to allow an UNDEF here.
> 
> Correction (I wasn't thinking): RES0 behavior should be invariant, much
> like the UNDEF behavior of the other AA32-specific registers.

I'm not sure what you're asking for exactly here, so let me explain my
understanding of the architecture on this point, which is that the
*32_EL2 registers are different in nature from the SPSR_* registers.

IFAR32_EL2 and co are accessors for the equivalent AArch32 registers.
If AArch32 isn't implemented, then these registers should UNDEF,
because there is nothing to access at all.

The status of SPSR_* is more subtle: the AArch32 exception model is
banked (irq, fiq, abt, und), and for each bank we have a triplet
(LR_*, SP_*, SPSR_*), plus the extra R[8-12]_fiq. On taking an
exception from AArch32 EL1 to AArch64 EL2, all the (LR_*, SP_*,
R*_fiq) are stored as part of the AArch64 GPRs (X16-X30, see I_PYKVS).

And what about SPSR_*? Well, they live as extra registers that are
populated on exception entry. But they are similar in nature to the
GPRs that store the rest of the stuff. When AArch32 isn't implemented,
the natural choice is to keep them around, only as RES0, because they
are just GPRs.

Of course, all of this is an architectural choice. If I had to change
anything, I'd rather have everything to UNDEF. But there is some logic
in the madness. And frankly, we will never see an AArch32-capable,
NV-capable HW implementation ever, so this is all fairly academic.

Cheers,

	M.

-- 
Without deviation from the norm, progress is not possible.