[PATCH v20 12/14] KVM: selftests: arm64: Only restore SPSR_EL1 and ELR_EL1 if they change

Leonardo Bras leo.bras at arm.com
Wed Sep 9 10:03:12 PDT 2026


On Tue, Sep 01, 2026 at 10:47:10PM +0100, Mark Brown wrote:
> When EXLOCK is enabled for ELx writes to SPSR_ELx and ELR_ELx generate
> GCS exceptions. Currently the selftest helpers unconditionally reload the
> saved values for these registers regardless of if the handler didn't change
> them. This gets in the way of EXLOCK testing, making it hard to generate
> contexts which will generate an invalid ERET since we never get as far as
> doing an exception return while EXLOCK is enabled.
> 
> In order to facilitate testing of nested virtualisation emulation of EXLOCK
> change our reloads into read/modify/write cycles, suppressing the writes
> when they would not change the value in the register.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  tools/testing/selftests/kvm/lib/arm64/handlers.S | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/tools/testing/selftests/kvm/lib/arm64/handlers.S b/tools/testing/selftests/kvm/lib/arm64/handlers.S
> index 0e443eadfac6..367c22d61cba 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/handlers.S
> +++ b/tools/testing/selftests/kvm/lib/arm64/handlers.S
> @@ -33,8 +33,18 @@
>  
>  .macro restore_registers
>  	ldp	x1, x2, [sp, #16 * 16] /* PC, PSTATE */
> +
> +	/* Suppress redundant writes to support GCS exception lock testing */
> +	mrs	x3, elr_el1
> +	cmp	x1, x3
> +	beq	.Lskip_elr_\@
>  	msr	elr_el1, x1
> +.Lskip_elr_\@:
> +	mrs	x3, spsr_el1
> +	cmp	x2, x3
> +	beq	.Lskip_spsr_\@
>  	msr	spsr_el1, x2
> +.Lskip_spsr_\@:
>  
>  	/* sp is not restored */
>  	ldp	x30, xzr, [sp, #16 * 15] /* x30, SP */
> 

Ok, looks fair.
I don't think there could be any effect that would happen only for writing 
to the register (when nothing was changed), so that should be safe (as long 
as it does _not_ run in multiple threads at the same time.


If that's the case:
Reviewed-by: Leonardo Bras <leo.bras at arm.com>

Thanks!
Leo



More information about the linux-arm-kernel mailing list