Re: [PATCH v2 1/2] RISC-V: KVM: Introduce make_xfence_request_nodata for FENCE.I requests

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Stranded `hfence_queue` entries cause permanent fallback to global TLB flushes.
--

--- Patch [1]: [PATCH v2 1/2] RISC-V: KVM: Introduce make_xfence_request_nodata for FENCE.I requests ---
commit c3b95cdce701530ec81cfa3b256ee7e3d2dd263d
Author: Wang Yechao <wang.yechao255@zte.com.cn>

RISC-V: KVM: Introduce make_xfence_request_nodata for FENCE.I requests

FENCE.I does not need hfence data, but it currently goes through the
generic make_xfence_request() path with NULL data, incurring unnecessary
per-VCPU checks. Split out a separate make_xfence_request_nodata() function
to handle FENCE.I directly, and move the data validity check to the top of
the generic function to avoid redundant checks.

> diff --git a/arch/riscv/kvm/tlb.c b/arch/riscv/kvm/tlb.c
> index 993b25ea94d67..5a9c75e458013 100644
> --- a/arch/riscv/kvm/tlb.c
> +++ b/arch/riscv/kvm/tlb.c

[ ... ]

> @@ -347,9 +373,6 @@ static void make_xfence_request(struct kvm *kvm,
>  
>  		bitmap_set(vcpu_mask, i, 1);
>  
> -		if (!data || !data->type)
> -			continue;
> -
>  		/*
>  		 * Enqueue hfence data to VCPU hfence queue. If we don't
>  		 * have space in the VCPU hfence queue then fallback to

[Severity: High]
This isn't a bug introduced by this patch, but can this loop in
make_xfence_request() cause a performance regression by stranding enqueued
items if a later enqueue fails?

If any vCPU's queue is full, vcpu_hfence_enqueue() fails, and the loop
overrides actual_req to fallback_req (e.g., KVM_REQ_TLB_FLUSH) for the entire
batch:

        if (!vcpu_hfence_enqueue(vcpu, data))
                actual_req = fallback_req;
}

kvm_make_vcpus_request_mask(kvm, actual_req, vcpu_mask);

The vCPUs that successfully enqueued the data earlier in the loop will receive
KVM_REQ_TLB_FLUSH instead of KVM_REQ_HFENCE. Since they process
KVM_REQ_TLB_FLUSH without dequeueing from their hfence_queue (which only
happens when processing KVM_REQ_HFENCE via kvm_riscv_hfence_process()), these
successfully enqueued items become permanently stranded.

As this repeats, the queues of healthy vCPUs will eventually fill up. Once a
queue is fully saturated with stranded items, it will permanently fail all
future enqueues, forcing all subsequent fine-grained requests to downgrade to
global TLB flushes for the lifetime of the VM.

>  		 * a more conservative hfence request.
>  		 */
> @@ -365,8 +388,7 @@ static void make_xfence_request(struct kvm *kvm,
>  void kvm_riscv_fence_i(struct kvm *kvm,
>  		       unsigned long hbase, unsigned long hmask)
>  {

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