On Wed, Sep 30, 2026 at 10:48:25PM +0100, Mark Brown wrote: > When running in vEL2 ERET is emulated, this means that we must emulate > the behaviour of GCSCR_EL2.EXLOCKEN. Add a test that validates the > behaviour. > > As per DDI0487 R_WTXBY PSTATE.EXLOCK is set to the value of > GCSCR_ELx.EXLOCKEN when taking an exception to the same exception level. > As per DDI0487 R_TYTWB if on exception return to the same EL > GCSCR_ELx.EXLOCKEN is 1 and PSTATE.EXLOCK is not 1 then the exception > return is illegal. > > We nest handling of two UDFs to allow us to both observe and modify > PSTATE.EXLOCK, checking that expected exceptions are generated for ERET. > We also repeat the UDF tests having enabled fine grained traps for ERET > to try to ensure that the slow paths are taken. > > We also attempt to write to both SPSR_ELx and ELR_ELx, again using a UDF > handler to control PSTATE.EXLOCK. We do all this both with and without > having enabled EXLOCKEN, though only for code running at EL2 due to > framework limitations. > > For completeness we also inject a data abort from EL0 to EL2 with > GCSCR_EL2.EXLOCKEN set, ensuring that PSTATE.EXLOCK is not set. > > Signed-off-by: Mark Brown <[email protected]> > Reviewed-by: Leonardo Bras <[email protected]>
This all seems reasonable test-wise, but I wonder if the discussion around 8/15 might alter some of what's tested here? In that - if it's only hardware that's doing the locked check then the SPSR (and probably ELR?) bits might only be exercising that rather than KVM stuff? It might only need a comment update though :) -- Cheers, Lorenzo
