Re: [PATCH v4 2/8] KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `kvm_vcpu_read_sys_reg()` and `kvm_vcpu_write_sys_reg()` are fundamentally unsafe for nVHE EL2 emulation (e.g., during `fixup_guest_exit`), despite the commit claiming they are "valid in any context".
--

commit 61ee8756572b776a9170ae13bb7ede91ed5afb18
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code

This commit moves the wrappers for vcpu_read_sys_reg and vcpu_write_sys_reg 
from exception.c to kvm_emulate.h as kvm_vcpu_read_sys_reg and 
kvm_vcpu_write_sys_reg. This makes them available to all hyp code so that 
emulation logic can be shared at EL2.

> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 5bf3d7e1d92c7..80b30fead3d16 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -506,6 +506,22 @@ static inline unsigned long kvm_vcpu_get_mpidr_aff(struct kvm_vcpu *vcpu)
>  	return __vcpu_sys_reg(vcpu, MPIDR_EL1) & MPIDR_HWID_BITMASK;
>  }
>  
> +static inline u64 kvm_vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg)
> +{
> +	if (has_vhe())
> +		return vcpu_read_sys_reg(vcpu, reg);
> +
> +	return __vcpu_sys_reg(vcpu, reg);
> +}

[Severity: High]
This is a pre-existing issue, but are these accessors actually safe for nVHE 
EL2 emulation? The commit message claims they are valid in any context, but
during early exit handling (like fixup_guest_exit), the live guest state is
still in hardware registers.

Because has_vhe() evaluates to false in nVHE EL2, kvm_vcpu_read_sys_reg() falls
back to reading the memory context via __vcpu_sys_reg(). This means it reads
stale state until __sysreg_save_state_nvhe() runs.

For example, when an exception is injected into a protected guest via
inject_sync64(), enter_exception64() uses this helper to read SCTLR_EL1 and
computes the new PSTATE from it. This reads a stale SCTLR_EL1, potentially
corrupting the injected PSTATE.SPAN and PSTATE.SSBS bits.

Could exposing these as generic helpers lead to more traps where EL2 code
accidentally reads stale memory-backed sysregs before they are synced?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706095927.560795-1-fuad.tabba@linux.dev?part=2