Re: [PATCH 2/2] RISC-V: KVM: Separate req and fallback_req masks in make_xfence_request

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch series silently drops FENCE.I requests by introducing an early return when `data` is NULL, breaking guest I-cache synchronization.
--

--- Patch [2]: [PATCH 2/2] RISC-V: KVM: Separate req and fallback_req masks in make_xfence_request ---
commit dc6a1097782a407911f8597843403d3a551a9225
Author: Wang Yechao <wang.yechao255@zte.com.cn>

RISC-V: KVM: Separate req and fallback_req masks in make_xfence_request

This commit modifies make_xfence_request() to maintain separate bitmaps
for vCPUs that successfully enqueue hfence data and those that require
fallback requests. It then applies the appropriate request to each group
separately.

> diff --git a/arch/riscv/kvm/tlb.c b/arch/riscv/kvm/tlb.c
> index a67b44a4d1d7a..916e2b1e0b366 100644
> --- a/arch/riscv/kvm/tlb.c
> +++ b/arch/riscv/kvm/tlb.c
> @@ -332,13 +332,14 @@ static void make_xfence_request(struct kvm *kvm,
>  {
>  	unsigned long i;
>  	struct kvm_vcpu *vcpu;
> -	unsigned int actual_req = req;
> -	DECLARE_BITMAP(vcpu_mask, KVM_MAX_VCPUS);
> +	DECLARE_BITMAP(req_vcpu_mask, KVM_MAX_VCPUS);
> +	DECLARE_BITMAP(fallback_req_vcpu_mask, KVM_MAX_VCPUS);
>  
>  	if (!data || !data->type)
>  		return;

[Severity: High]
Does this early return unconditionally abort the function when data is NULL,
preventing KVM_REQ_FENCE_I from ever being processed and skipping the vCPU
mask creation?

Looking at kvm_riscv_fence_i() in arch/riscv/kvm/tlb.c, it explicitly passes
NULL for data:

void kvm_riscv_fence_i(struct kvm *kvm,
		       unsigned long hbase, unsigned long hmask)
{
	make_xfence_request(kvm, hbase, hmask, KVM_REQ_FENCE_I,
			    KVM_REQ_FENCE_I, NULL);
}

When a guest triggers SBI_EXT_RFENCE_REMOTE_FENCE_I, it invokes
kvm_riscv_fence_i(). Because data is NULL, make_xfence_request() returns
immediately without setting the KVM_REQ_FENCE_I bit or kicking the target
vCPUs.

Can this missing I-cache flush cause a guest to execute stale instructions,
leading to unpredictable guest behavior, kernel panics, or data corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707113715.413265-1-wang.yechao255@zte.com.cn?part=2