Re: [PATCH v2 2/7] KVM: arm64: Unconditionally set IL for injected undefined exceptions

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Nested SError exception injection silently drops the ESR_EL2 value.
--

commit e7d1337c1e8d6db55c7b9ce2682f4c52e85c3f44
Author: Fuad Tabba <tabba@google.com>

KVM: arm64: Unconditionally set IL for injected undefined exceptions

This commit simplifies the inject_undef64() exception injection path by
unconditionally setting the IL bit, as the architecture mandates IL=1 for
EC=0 (Unknown).

> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 89982bd3345f6..9dfae1bcdf992 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -170,14 +170,7 @@ void kvm_inject_sync(struct kvm_vcpu *vcpu, u64 esr)
>  
>  static void inject_undef64(struct kvm_vcpu *vcpu)
>  {
> -	u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
> -
> -	/*
> -	 * Build an unknown exception, depending on the instruction
> -	 * set.
> -	 */
> -	if (kvm_vcpu_trap_il_is32bit(vcpu))
> -		esr |= ESR_ELx_IL;
> +	u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL;
>  
>  	kvm_inject_sync(vcpu, esr);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the exception
injection changes, I noticed a pre-existing issue in the nested SError
injection path.

In arch/arm64/kvm/emulate-nested.c, kvm_inject_nested_serror() constructs
the ESR for the nested SError and passes it down to kvm_inject_nested():

arch/arm64/kvm/emulate-nested.c:kvm_inject_nested_serror() {
	...
	esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
	return kvm_inject_nested(vcpu, esr, except_type_serror);
}

However, when this esr reaches kvm_inject_el2_exception(), the value is
silently discarded:

arch/arm64/kvm/emulate-nested.c:kvm_inject_el2_exception() {
	...
	switch (type) {
	case except_type_sync:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SYNC);
		vcpu_write_sys_reg(vcpu, esr_el2, ESR_EL2);
		break;
	case except_type_irq:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_IRQ);
		break;
	case except_type_serror:
		kvm_pend_exception(vcpu, EXCEPT_AA64_EL2_SERR);
		break;
	...
}

Because the except_type_serror case breaks without writing esr_el2 to
ESR_EL2 (unlike the except_type_sync case), the constructed syndrome is
completely dropped.

Since enter_exception64() does not dynamically update ESR_ELx, will the
guest hypervisor observe a stale ESR_EL2 when handling the injected SError?

Could this cause the guest to misinterpret the error, potentially leading
to incorrect functional behavior or a guest panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618121643.4105064-1-tabba@google.com?part=2