Re: [PATCH v21 08/15] KVM: arm64: Enforce EXLOCK for SPSR and ELR

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Sep 30, 2026 at 10:48:18PM +0100, Mark Brown wrote:
> As per I_CFFNS and the pseudocode for the SPSR_ELx and ELR_ELx registers
> a GCS exception with ExType 1 is generated for attempts to write to
> those registers when both GCSCR_ELx.EXLOCKEN and PSTATE.EXLOCK are set.

From [4] I see I_CFFNS is defined as:

"When an MSR instruction would write to the relevant ELR_ELx or SPSR_ELx
for the current Exception level ELy, the Effective value of
GCSCR_ELy.EXLOCKEN and PSTATE.EXLOCK may prevent the write."

So the lock applies to writes to the current EL's own ELR/SPSR rather than
to any ELR_ELx/SPSR_ELx the current EL can write to?

> Ensure that this is enforced for guests if access to these registers
> from the guest is handled by the hypervisor.
>
> Reviewed-by: Leonardo Bras <leo.bras@arm.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/kvm_emulate.h |  8 +++++++
>  arch/arm64/kvm/sys_regs.c            | 42 ++++++++++++++++++++++++++++++++----
>  2 files changed, 46 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 0cd91b3d6c82..e47ab38327de 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -81,6 +81,14 @@ int kvm_inject_nested_irq(struct kvm_vcpu *vcpu);
>  int kvm_inject_nested_sea(struct kvm_vcpu *vcpu, bool iabt, u64 addr);
>  int kvm_inject_nested_serror(struct kvm_vcpu *vcpu, u64 esr);
>
> +static inline void kvm_inject_exlock(struct kvm_vcpu *vcpu)
> +{
> +	u64 esr = FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_GCS) | ESR_ELx_IL |
> +		  FIELD_PREP(ESR_ELx_ExType_MASK, ESR_ELx_ExType_EXLOCK);
> +
> +	kvm_inject_sync(vcpu, esr);
> +}
> +
>  static inline void kvm_inject_nested_sve_trap(struct kvm_vcpu *vcpu)
>  {
>  	u64 esr = FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SVE) |
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 823460106de8..faecf4657ec5 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2866,14 +2866,42 @@ static bool access_sp_el1(struct kvm_vcpu *vcpu,
>  	return true;
>  }
>
> +static inline bool sysregs_exlocked(struct kvm_vcpu *vcpu)

So if this returns true, an EXLOCKException is raised, otherwise SPSR_EL1
is set (based on caller below).

From [0] the pseudocode for MSR SPSR_EL1, <Xt> is:

elsif PSTATE.EL == EL2 then
    if IsFeatureImplemented(FEAT_GCS) && GetCurrentEXLOCKEN() && !Halted() && PSTATE.EXLOCK == '1' && ELIsInHost(EL2) then
        EXLOCKException();
    elsif ELIsInHost(EL2) then
        SPSR_EL2() = X{64}(t);
    else
        SPSR_EL1() = X{64}(t);
    end;

Reading [2] and [3], ELIsInHost(EL2) is equivalent to vcpu_el2_e2h_is_set(),
but the code doesn't check this anywhere?

The calling function only ever writes to SPSR_EL1, which implies
!ELIsInHost() (I guess because if it is true the writes are just done
directly to registers?)

But if that's always false, then an exception can never be raised due to
the first condition being false, and then the whole thing collapses to
SPSR_EL1() = X{64}(t).

So PSTATE.EL == EL2 is ~ I gather to is_hyp_ctxt() (guest's view of its own
EL) and thus this would be equivalent to:

if (is_hyp_ctxt())
	return false;

Wouldn't it?

But for the PSTATE.EL == EL1 branch (what the hardware runs for a vEL2
guest), also from [0]:

    if IsFeatureImplemented(FEAT_GCS) && GetCurrentEXLOCKEN() && !Halted() && PSTATE.EXLOCK == '1' && !(EffectiveHCR_EL2_NVx() IN {'x11'}) then
        EXLOCKException();
    elsif IsFeatureImplemented(FEAT_S1POE2) && EffectiveHCR_EL2_NVx() IN {'x11'} && FGDTState.nH == '1' then
        AArch64_FGDTSystemAccessTrap(EL1, 0x18);
    elsif EffectiveHCR_EL2_NVx() == '011' then
        AArch64_SystemAccessTrap(EL2, 0x18);
    elsif EffectiveHCR_EL2_NVx() IN {'111'} then
        NVMem(0x160) = X{64}(t);
    else
        SPSR_EL1() = X{64}(t);
    end;

EffectiveHCR_EL2_NVx() (see [5]) obtains the nested virt configuration
based on HCR flags.

In __compute_hcr():

static u64 __compute_hcr(struct kvm_vcpu *vcpu)
{
	...

	if (is_hyp_ctxt(vcpu)) {
		...
		hcr |= HCR_NV | HCR_NV2 | HCR_AT | HCR_TTLB;
		if (!vcpu_el2_e2h_is_set(vcpu))
			hcr |= HCR_NV1;
		...
	}
	...
}

So for a vEL2 guest this is either '101' (guest E2H=1), or '111' (guest E2H=0).

So that leaves us with:

    if IsFeatureImplemented(FEAT_GCS) && GetCurrentEXLOCKEN() && !Halted() && PSTATE.EXLOCK == '1' && !(EffectiveHCR_EL2_NVx() IN {'x11'}) then
        EXLOCKException();
    elsif EffectiveHCR_EL2_NVx() IN {'111'} then
        NVMem(0x160) = X{64}(t);
    else
        SPSR_EL1() = X{64}(t);

And from include/asm/vncr_mapping.h:

#define VNCR_SPSR_EL1           0x160

So that's the VNCR write that the hardware does.

So for '101' the hardware does the EXLOCK check and the write
itself, for '111' the check is skipped and the write goes to the VNCR page.

In both cases, nothing traps to KVM (only '011', NV1 without NV2 would -
but KVM never configures that as it requires NV2).

So... TL;DR is, shouldn't this function look like:

static inline bool sysregs_exlocked(struct kvm_vcpu *vcpu)
{
	if (!kvm_has_gcs(vcpu->kvm))
		return false;

	if (!(vcpu->arch.ctxt.regs.pstate & PSR_EXLOCK_BIT))
		return false;

	if (is_hyp_ctxt(vcpu))
		return false;

	return vcpu_read_sys_reg(vcpu, GCSCR_EL1) & GCSCR_ELx_EXLOCKEN;
}

?

> +{
> +	u64 gcscr;
> +
> +	if (!kvm_has_gcs(vcpu->kvm))
> +		return false;
> +
> +	if (!(vcpu->arch.ctxt.regs.pstate & PSR_EXLOCK_BIT))
> +		return false;
> +
> +	/*
> +	 * Note that the EXLOCKEN for the running EL is checked
> +	 * regardless of the register written to.
> +	 */

This seems to contradict [4] - the register written to is what decides
whether the lock applies?

> +	if (is_hyp_ctxt(vcpu))
> +		gcscr = vcpu_read_sys_reg(vcpu, GCSCR_EL2);
> +	else
> +		gcscr = vcpu_read_sys_reg(vcpu, GCSCR_EL1);

GetCurrentEXLOCKEN() is defined in [1] as:

    ...
    case PSTATE.EL of
	...
        when EL1 =>
            return GCSCR_EL1().EXLOCKEN == ‘1’;
        when EL2 =>
            return GCSCR_EL2().EXLOCKEN == ‘1’;
	...
    end;

And is_hyp_ctxt() -> PSTATE.EL == 2, else -> PSTATE.EL == 1 so this matches up with:

> +
> +	return gcscr & GCSCR_ELx_EXLOCKEN;

Where this is the .EXLOCKEN == '1' bit.

> +}
> +
>  static bool access_elr(struct kvm_vcpu *vcpu,
>  		       struct sys_reg_params *p,
>  		       const struct sys_reg_desc *r)
>  {
> -	if (p->is_write)
> +	if (p->is_write) {
> +		if (sysregs_exlocked(vcpu)) {
> +			kvm_inject_exlock(vcpu);
> +			return false;
> +		}
> +

(I assume ELR mirrors SPSR but I haven't checked).

>  		vcpu_write_sys_reg(vcpu, p->regval, ELR_EL1);
> -	else
> +	} else {
>  		p->regval = vcpu_read_sys_reg(vcpu, ELR_EL1);
> +	}
>
>  	return true;
>  }
> @@ -2882,10 +2910,16 @@ static bool access_spsr(struct kvm_vcpu *vcpu,
>  			struct sys_reg_params *p,
>  			const struct sys_reg_desc *r)
>  {
> -	if (p->is_write)
> +	if (p->is_write) {
> +		if (sysregs_exlocked(vcpu)) {
> +			kvm_inject_exlock(vcpu);
> +			return false;
> +		}
> +
>  		__vcpu_assign_sys_reg(vcpu, SPSR_EL1, p->regval);
> -	else
> +	} else {
>  		p->regval = __vcpu_sys_reg(vcpu, SPSR_EL1);
> +	}
>
>  	return true;
>  }
>
> --
> 2.47.3
>
>

[0]:https://support.arm.com/documentation/111107/2026-09/AArch64-Registers/SPSR-EL1--Saved-Program-Status-Register--EL1-?lang=en
[1]:https://support.arm.com/documentation/ddi0487/md/-Part-J-Architectural-Pseudocode/-Chapter-J1-A-profile-Architecture-Pseudocode/-J1-2-Pseudocode-for-AArch64-operation/-J1-2-267-GetCurrentEXLOCKEN
[2]:https://support.arm.com/documentation/ddi0487/md/-Part-J-Architectural-Pseudocode/-Chapter-J1-A-profile-Architecture-Pseudocode/-J1-4-Shared-pseudocode/-J1-4-552-ELIsInHost?lang=en
[3]:https://support.arm.com/documentation/ddi0487/md/-Part-J-Architectural-Pseudocode/-Chapter-J1-A-profile-Architecture-Pseudocode/-J1-4-Shared-pseudocode/-J1-4-558-EffectiveHCR-EL2-E2H?lang=en
[4]:https://support.arm.com/documentation/ddi0487/md/-Part-D-The-AArch64-System-Level-Architecture/-Chapter-D11-The-Guarded-Control-Stack/-D11-4-Exception-returns/-D11-4-1-Pushing-and-popping-exception-return-state?lang=en
[5]:https://support.arm.com/documentation/ddi0487/md/-Part-J-Architectural-Pseudocode/-Chapter-J1-A-profile-Architecture-Pseudocode/-J1-4-Shared-pseudocode/-J1-4-559-EffectiveHCR-EL2-NVx?lang=en

--
Cheers, Lorenzo