Re: [PATCH 07/28] KVM: arm64: Don't evaluate HCR_EL2.NV on ERET fast path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `kvm_hyp_handle_eret` fast-path incorrectly evaluates an L1 hypervisor's virtual `HFGITR_EL2` register to determine if L1's own `ERET` should be optimized. Because `is_nested_ctxt(vcpu)` is false for L1, the condition falls through to check `__vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET`. This virtual register reflects L1's trap configuration for its L2 guest, and has no architectural bearing on L1's own execution. If L1 configures L2's ERETs to trap, KVM will spuriously abort the fast-path for L1's local ERETs. (For L2, the check is dead code since `is_nested_ctxt(vcpu)` short-circuits it).
--

commit b3baa466fe54b91fd60bc2025656ec74bb249ab9
Author: Marc Zyngier <maz@kernel.org>

KVM: arm64: Don't evaluate HCR_EL2.NV on ERET fast path

This commit replaces the check for HCR_EL2.NV in the ERET fast path with
a check for is_nested_ctxt(). This ensures we evaluate if we are actually
running an L2 guest, rather than just checking if HCR_EL2.NV is set.

> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> index bbe9cebd3d9d5..3b76e0468317b 100644
> --- a/arch/arm64/kvm/hyp/vhe/switch.c
> +++ b/arch/arm64/kvm/hyp/vhe/switch.c

[ ... ]

> @@ -349,8 +349,8 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code)
>  	 * Unless the trap has to be forwarded further down the line,
>  	 * of course...
>  	 */
> -	if ((__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV) ||
> -	    (__vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET))
> +	if (is_nested_ctxt(vcpu) ||
> +	    __vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET)

[Severity: Medium]
Will this apply L1's virtual trap configuration to L1's own execution?

Since is_nested_ctxt(vcpu) is true for L2 guests, this condition will
short-circuit and the HFGITR_EL2 check becomes dead code for L2.

For an L1 guest, is_nested_ctxt(vcpu) is false, causing it to evaluate the
HFGITR_EL2 check. However, this virtual register reflects L1's trap
configuration for its L2 guest and doesn't apply to L1's own execution.

If L1 configures L2's ERETs to trap, won't KVM spuriously abort the
fast-path for L1's local ERETs and incorrectly fall back to the slow path?

>  		return false;
>  
>  	spsr = read_sysreg_el1(SYS_SPSR);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702160248.1377250-1-maz@kernel.org?part=7