Re: [PATCH v4 6/8] RISC-V: KVM: Delegate SPELP bit to VS/VU mode if landing pad is enabled.

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing clearance of SR_SPELP in guest_context.sstatus during trap redirection causes the guest to resume with an incorrect ELP state, leading to spurious landing pad faults.
--

commit 2ec992c0d3b802f1fb7b83ffb3d6328de134362d
Author: Inochi Amaoto <inochiama@gmail.com>

RISC-V: KVM: Delegate SPELP bit to VS/VU mode if landing pad is enabled.

This patch delegates the newly added SPELP bit from the Zicfilp extension
to VS/VU mode if it enables landing pad support.

> diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
> --- a/arch/riscv/kvm/vcpu_exit.c
> +++ b/arch/riscv/kvm/vcpu_exit.c
> @@ -154,6 +154,12 @@ void kvm_riscv_vcpu_trap_redirect(struct kvm_vcpu *vcpu,
>  	/* Clear Guest SSTATUS.SIE bit */
>  	vsstatus &= ~SR_SIE;
>  
> +	/* Change Guest SSTATUS.SPELP bit */
> +	if (vcpu->arch.cfg.henvcfg & ENVCFG_LPE) {
> +		vsstatus &= ~SR_SPELP;
> +		vsstatus |= vcpu->arch.guest_context.sstatus & SR_SPELP;

[Severity: High]
Does this missing clearance cause the guest to resume with an incorrect ELP
state?

While this correctly saves the old ELP state to vsstatus, it appears to
leave SR_SPELP set in vcpu->arch.guest_context.sstatus. If a guest with
the Zicfilp extension enabled takes an exception while its active ELP state
is 1, won't the guest's exception handler be entered with an active ELP
state of 1 instead of 0?

Could this cause an immediate Software Check exception (landing pad fault)
when the guest exception handler executes its first instruction, resulting
in a trap loop or guest crash?

> +	}
> +
>  	/* Update Guest SSTATUS */
>  	ncsr_write(CSR_VSSTATUS, vsstatus);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701020746.170157-1-inochiama@gmail.com?part=6