Re: [PATCH v21 15/15] KVM: selftests: arm64: Add GCS EXLOCK exception emulation test

[Lorenzo Stoakes (ARM)]

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 <broonie@xxxxxxxxxx>
> Reviewed-by: Leonardo Bras <leo.bras@xxxxxxx>

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