From: sashiko-bot@kernel.org
To: "Wang Yechao" <wang.yechao255@zte.com.cn>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] RISC-V: KVM: Move hfence type check out of loop
Date: Tue, 07 Jul 2026 11:45:10 +0000 [thread overview]
Message-ID: <20260707114510.707C71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260707113715.413265-2-wang.yechao255@zte.com.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch completely breaks KVM_REQ_FENCE_I requests by unconditionally returning early from `make_xfence_request` when `data` is NULL, silently dropping guest instruction cache invalidations.
--
--- Patch [1]: [PATCH 1/2] RISC-V: KVM: Move hfence type check out of loop ---
commit 7dbdb7321dcb98c78f1282572934fc7ae89bab7e
Author: Wang Yechao <wang.yechao255@zte.com.cn>
RISC-V: KVM: Move hfence type check out of loop
This commit moves the validation of data and data->type outside the
VCPU iteration loop in make_xfence_request() to reduce overhead. It
adds an early return if the hfence data or its type is invalid.
> diff --git a/arch/riscv/kvm/tlb.c b/arch/riscv/kvm/tlb.c
> index 993b25ea94d67..a67b44a4d1d7a 100644
> --- a/arch/riscv/kvm/tlb.c
> +++ b/arch/riscv/kvm/tlb.c
> @@ -335,6 +335,9 @@ static void make_xfence_request(struct kvm *kvm,
> unsigned int actual_req = req;
> DECLARE_BITMAP(vcpu_mask, KVM_MAX_VCPUS);
>
> + if (!data || !data->type)
> + return;
> +
[Severity: High]
Does this early return break callers that intentionally pass NULL for data?
For example, kvm_riscv_fence_i() calls make_xfence_request() with data=NULL
to broadcast a KVM_REQ_FENCE_I request:
arch/riscv/kvm/tlb.c:kvm_riscv_fence_i() {
...
make_xfence_request(kvm, hbase, hmask, KVM_REQ_FENCE_I,
KVM_REQ_FENCE_I, NULL);
...
}
In the old code, passing NULL skipped enqueueing to the hfence queue but still
allowed the loop to populate vcpu_mask, so the request was properly broadcast.
With this change, the function returns immediately, dropping guest instruction
cache invalidations. Could this lead to guests executing stale instructions?
> bitmap_zero(vcpu_mask, KVM_MAX_VCPUS);
> kvm_for_each_vcpu(i, vcpu, kvm) {
> if (hbase != -1UL) {
[ ... ]
> @@ -347,9 +350,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
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260707113715.413265-1-wang.yechao255@zte.com.cn?part=1
next prev parent reply other threads:[~2026-07-07 11:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 11:37 [PATCH 0/2] RISC-V: KVM: Optimize hfence request handling for SMP guests Wang Yechao
2026-07-07 11:37 ` Wang Yechao
2026-07-07 11:37 ` Wang Yechao
2026-07-07 11:37 ` [PATCH 1/2] RISC-V: KVM: Move hfence type check out of loop Wang Yechao
2026-07-07 11:37 ` Wang Yechao
2026-07-07 11:37 ` Wang Yechao
2026-07-07 11:45 ` sashiko-bot [this message]
2026-07-07 11:37 ` [PATCH 2/2] RISC-V: KVM: Separate req and fallback_req masks in make_xfence_request Wang Yechao
2026-07-07 11:37 ` Wang Yechao
2026-07-07 11:37 ` Wang Yechao
2026-07-07 11:47 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260707114510.707C71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wang.yechao255@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.