On Wed, 25 Oct 2023 00:04:27 +0100, Oliver Upton <oliver.upton@xxxxxxxxx> 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@xxxxxxxxxx> 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.
