Re: [PATCH v2] RISC-V: KVM: Add kvm-riscv.wfi_trap_policy to control VS-mode WFI trapping

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:
- [High] The dynamic WFI trap policy check is performed only in `kvm_arch_v=
cpu_load()`, leading to a TOCTOU race that causes CPU starvation for newly =
awakened tasks.
- [Low] Using `early_param` in a tristate KVM module breaks the build when =
KVM is compiled as a loadable module (`CONFIG_KVM=3Dm`).
--

--- Patch [1]: [PATCH v2] RISC-V: KVM: Add kvm-riscv.wfi_trap_policy to con=
trol VS-mode WFI trapping ---
commit 74512223938eb34f8681ae4dfb342e0d3e2fc417
Author: Yuhang.Chen <[email protected]>
Subject: RISC-V: KVM: Add kvm-riscv.wfi_trap_policy to control VS-mode WFI =
trapping

This patch adds a kernel command-line option to control whether a WFI
executed by a VS-mode guest traps into KVM or executes natively. The
policy can be 'trap' or 'auto', with 'auto' dynamically allowing native
WFI only when the vCPU is the sole runnable task.

> diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
> index 977e36ab83d3f..9a4a7d0729d37 100644
> --- a/arch/riscv/kvm/vcpu.c
> +++ b/arch/riscv/kvm/vcpu.c
> @@ -26,6 +28,59 @@
> =20
>  static DEFINE_PER_CPU(struct kvm_vcpu *, kvm_former_vcpu);
> =20
> +/*
> + * WFI trap policy for VS-mode guests, controllable through the
> + * kvm-riscv.wfi_trap_policy=3D kernel command-line option.
> + */

[ ... ]

> +static int __init early_kvm_riscv_wfi_trap_policy_cfg(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	if (strcmp(arg, "trap") =3D=3D 0) {
> +		kvm_riscv_wfi_trap_policy =3D KVM_RISCV_WFI_TRAP;
> +		return 0;
> +	}
> +
> +	if (strcmp(arg, "auto") =3D=3D 0) {
> +		kvm_riscv_wfi_trap_policy =3D KVM_RISCV_WFI_AUTO;
> +		return 0;
> +	}
> +
> +	return -EINVAL;
> +}
> +early_param("kvm-riscv.wfi_trap_policy", early_kvm_riscv_wfi_trap_policy=
_cfg);

[Severity: Low]
Does using early_param() break the build when KVM is compiled as a loadable
module (CONFIG_KVM=3Dm)?

The early_param macro defined in include/linux/init.h is strictly wrapped in
an #ifndef MODULE block, leaving it undefined for loadable modules.

Since early_kvm_riscv_wfi_trap_policy_cfg() relies on this macro, would
compiling with CONFIG_KVM=3Dm result in implicit declaration or undefined m=
acro
errors?

[ ... ]

> @@ -637,6 +693,9 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cp=
u)
> =20
>  	kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
> =20
> +	/* Re-evaluate the WFI trap policy for this vCPU. */
> +	kvm_riscv_vcpu_update_wfi_trap(vcpu);
> +
>  	vcpu->cpu =3D cpu;
>  }

[Severity: High]
Is there a time-of-check to time-of-use race here that could cause CPU
starvation for newly awakened tasks?

The policy is evaluated in kvm_arch_vcpu_load(), which clears HSTATUS.VTW
when the vCPU is the sole runnable task.

If an interrupt wakes another task on the same CPU while the vCPU is in the
guest, but preemption is not immediately forced (e.g., the vCPU still has C=
FS
timeslice remaining), KVM handles the exit and re-enters the guest loop in
kvm_arch_vcpu_ioctl_run() without calling kvm_arch_vcpu_load().

Could the guest then execute WFI natively because HSTATUS.VTW remains stale
and cleared, halting the physical CPU and starving the newly woken task unt=
il
the next hardware interrupt?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804024707.2400=
[email protected]?part=3D1