From nobody Fri Oct 2 13:07:19 2026 Received: from mxde.zte.com.cn (mxde.zte.com.cn [209.9.37.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4152B1DFFD; Fri, 31 Jul 2026 09:42:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.9.37.142 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785490944; cv=none; b=kH8BXSw/y1yHn2Was7d2l9NyJWHuiGh0MIydRdl/1vaTmlx+FNC11zlv8Z+ySp7/dSEOhv1cUjj4TL3f911n7tDreT033mI4zf0vVNFeUFFForhBWrYS/JPXj7JZDrGsqNdT6U87F17lkqC5yg7VdvmoDM0Zo5MVKDeHL0drsmo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785490944; c=relaxed/simple; bh=F5Duj1RDlRGR5Pdz+sOOdujfE4vAudRuiRmPsoFSVmY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=R3CjiGv3HEir4vK4lhvSDxDaj4MpibaLoJBa4QzIyOFFBfjbdnXn1HEcVbjewTxnih8CUaesFrkVCYM7Lc/0eAtKSbQYtIay/VP6O4Xd9ARgcqTrv1SJuNo1UY8OI8ox1+Qo1XXLTcjmF6zgUw9oFUEkBMTF9Kb6C7BERk14zSM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zte.com.cn; spf=pass smtp.mailfrom=zte.com.cn; arc=none smtp.client-ip=209.9.37.142 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zte.com.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zte.com.cn Received: from mxhk.zte.com.cn (unknown [192.168.250.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mxde.zte.com.cn (FangMail) with ESMTPS id 4hBLh619yCzBF0Zm; Fri, 31 Jul 2026 17:42:14 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4hBLgw67mtz5B0wH; Fri, 31 Jul 2026 17:42:04 +0800 (CST) Received: from szxl2zmapp06.zte.com.cn ([10.1.32.108]) by mse-fl2.zte.com.cn with SMTP id 66V9ftFZ009379; Fri, 31 Jul 2026 17:41:55 +0800 (+08) (envelope-from wang.yechao255@zte.com.cn) Received: from localhost.localdomain (unknown [10.234.74.162]) by smtp (Zmail) with SMTP; Fri, 31 Jul 2026 17:41:58 +0800 X-Zmail-TransId: 3e816a6c6de5010-3f314 X-Zmail-LocalSMTP: 1 X-ZMAIL-USEORIGINALEMLTOOUTBOUND: 1 X-Zmail-RealSender: wang.yechao255@zte.com.cn From: Wang Yechao To: Anup Patel , kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Atish Patra , Alexandre Ghiti , Wang Yechao Subject: [PATCH v3 1/2] RISC-V: KVM: Separate req and fallback_req masks in make_xfence_request Date: Fri, 31 Jul 2026 17:38:27 +0800 Message-ID: <20260731093833.1551341-2-wang.yechao255@zte.com.cn> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20260731093833.1551341-1-wang.yechao255@zte.com.cn> References: <20260731093833.1551341-1-wang.yechao255@zte.com.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MAIL: mse-fl2.zte.com.cn 66V9ftFZ009379 X-TLS: YES X-ENVELOPE-SENDER: wang.yechao255@zte.com.cn X-SOURCE-IP: 192.168.250.138 unknown Fri, 31 Jul 2026 17:42:14 +0800 X-CLEAN: YES X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6A6C6DF4.000/4hBLh619yCzBF0Zm Content-Type: text/plain; charset="utf-8" When handling hfence requests in make_xfence_request(), the current code uses a single 'actual_req' variable and a single vcpu_mask. If any VCPU fails to enqueue the hfence data (because its queue is full), the request falls back to 'fallback_req' for all VCPUs, even if other VCPUs still have available queue space. This can cause unnecessary fallback for healthy VCPUs, and more seriously, those healthy VCPUs will not process their already-enqueued hfence requests because no 'req' is set for them. As a result, their queues will quickly become full as well, degrading performance for SMP guests. Fix this by maintaining two separate bitmaps: one for VCPUs that successfully enqueued the hfence data (req_vcpu_mask) and another for those that failed (fallback_req_vcpu_mask). Then send the appropriate requests to each group. This ensures that fallback is only applied to VCPUs that actually need it, preserving the efficiency of the normal path for others. Fixes: 13acfec2dbcc ("RISC-V: KVM: Add remote HFENCE functions based on VCP= U requests") Signed-off-by: Wang Yechao Reviewed-by: Anup Patel --- arch/riscv/kvm/tlb.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/arch/riscv/kvm/tlb.c b/arch/riscv/kvm/tlb.c index 993b25ea94d67..c54522decaa64 100644 --- a/arch/riscv/kvm/tlb.c +++ b/arch/riscv/kvm/tlb.c @@ -332,10 +332,11 @@ static void make_xfence_request(struct kvm *kvm, { unsigned long i; struct kvm_vcpu *vcpu; - unsigned int actual_req =3D 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); =20 - bitmap_zero(vcpu_mask, KVM_MAX_VCPUS); + bitmap_zero(req_vcpu_mask, KVM_MAX_VCPUS); + bitmap_zero(fallback_req_vcpu_mask, KVM_MAX_VCPUS); kvm_for_each_vcpu(i, vcpu, kvm) { if (hbase !=3D -1UL) { if (vcpu->vcpu_id < hbase || @@ -345,10 +346,10 @@ static void make_xfence_request(struct kvm *kvm, continue; } =20 - bitmap_set(vcpu_mask, i, 1); - - if (!data || !data->type) + if (!data || !data->type) { + bitmap_set(req_vcpu_mask, i, 1); continue; + } =20 /* * Enqueue hfence data to VCPU hfence queue. If we don't @@ -356,10 +357,13 @@ static void make_xfence_request(struct kvm *kvm, * a more conservative hfence request. */ if (!vcpu_hfence_enqueue(vcpu, data)) - actual_req =3D fallback_req; + bitmap_set(fallback_req_vcpu_mask, i, 1); + else + bitmap_set(req_vcpu_mask, i, 1); } =20 - kvm_make_vcpus_request_mask(kvm, actual_req, vcpu_mask); + kvm_make_vcpus_request_mask(kvm, req, req_vcpu_mask); + kvm_make_vcpus_request_mask(kvm, fallback_req, fallback_req_vcpu_mask); } =20 void kvm_riscv_fence_i(struct kvm *kvm, --=20 2.39.3 From nobody Fri Oct 2 13:07:19 2026 Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BFDC2B9B7; Fri, 31 Jul 2026 09:42:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=160.30.148.35 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785490929; cv=none; b=Ib8JqwEo9vkZfpEUvuC5spCaev7f53WKKdA/be3nOfXJ63kauGSNMQ5PJJ+0+9fAEQpuPVyOf3jpCcINf4pDgJK8S2oCO2m/SFk4Wh/wI5t3zTAtSUAZzV3gmEXULknvDXNVGdCiR+K0PkBt6BFycBf83ejyR9h3qux+vZNP+qM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785490929; c=relaxed/simple; bh=mGJwlffZRaEy5VRIHrqzNQqe27m55tgT2pTC2+zHauw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=iJNe0hxwLCTHV6nfTLByn2iFr1jPWsrCH1G6SfBFEm/RHOKx/NaYYjxDFv9faBhUynJELCYdbE+HP3NuzcaBD5ohHBaxgUn8WzQDrUY0hvzaHaXma7VuRoU7RGXoyam4cZOvH8HP6ztexEzxAeBfNmsch2dpJQ4eIGe0RiQS1Ww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zte.com.cn; spf=pass smtp.mailfrom=zte.com.cn; arc=none smtp.client-ip=160.30.148.35 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zte.com.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zte.com.cn Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4hBLgx2dvcz8Xrrq; Fri, 31 Jul 2026 17:42:05 +0800 (CST) Received: from szxl2zmapp06.zte.com.cn ([10.1.32.108]) by mse-fl2.zte.com.cn with SMTP id 66V9fvqc009430; Fri, 31 Jul 2026 17:41:57 +0800 (+08) (envelope-from wang.yechao255@zte.com.cn) Received: from localhost.localdomain (unknown [10.234.74.162]) by smtp (Zmail) with SMTP; Fri, 31 Jul 2026 17:42:00 +0800 X-Zmail-TransId: 3e816a6c6de7010-3f327 X-Zmail-LocalSMTP: 1 X-ZMAIL-USEORIGINALEMLTOOUTBOUND: 1 X-Zmail-RealSender: wang.yechao255@zte.com.cn From: Wang Yechao To: Anup Patel , kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Atish Patra , Alexandre Ghiti , Wang Yechao Subject: [PATCH v3 2/2] RISC-V: KVM: Introduce make_xfence_request_nodata for FENCE.I requests Date: Fri, 31 Jul 2026 17:38:28 +0800 Message-ID: <20260731093833.1551341-3-wang.yechao255@zte.com.cn> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20260731093833.1551341-1-wang.yechao255@zte.com.cn> References: <20260731093833.1551341-1-wang.yechao255@zte.com.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MAIL: mse-fl2.zte.com.cn 66V9fvqc009430 X-TLS: YES X-ENVELOPE-SENDER: wang.yechao255@zte.com.cn X-SOURCE-IP: 10.5.228.133 unknown Fri, 31 Jul 2026 17:42:05 +0800 X-CLEAN: YES X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6A6C6DED.000/4hBLgx2dvcz8Xrrq Content-Type: text/plain; charset="utf-8" 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. Signed-off-by: Wang Yechao Reviewed-by: Anup Patel --- arch/riscv/kvm/tlb.c | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/arch/riscv/kvm/tlb.c b/arch/riscv/kvm/tlb.c index c54522decaa64..fd445e9fa3f94 100644 --- a/arch/riscv/kvm/tlb.c +++ b/arch/riscv/kvm/tlb.c @@ -325,6 +325,29 @@ void kvm_riscv_hfence_process(struct kvm_vcpu *vcpu) } } =20 +static void make_xfence_request_nodata(struct kvm *kvm, unsigned long hbas= e, + unsigned long hmask, unsigned int req) +{ + unsigned long i; + struct kvm_vcpu *vcpu; + DECLARE_BITMAP(vcpu_mask, KVM_MAX_VCPUS); + + bitmap_zero(vcpu_mask, KVM_MAX_VCPUS); + kvm_for_each_vcpu(i, vcpu, kvm) { + if (hbase !=3D -1UL) { + if (vcpu->vcpu_id < hbase || + vcpu->vcpu_id >=3D hbase + BITS_PER_LONG) + continue; + if (!(hmask & (1UL << (vcpu->vcpu_id - hbase)))) + continue; + } + + bitmap_set(vcpu_mask, i, 1); + } + + kvm_make_vcpus_request_mask(kvm, req, vcpu_mask); +} + static void make_xfence_request(struct kvm *kvm, unsigned long hbase, unsigned long hmask, unsigned int req, unsigned int fallback_req, @@ -335,6 +358,9 @@ static void make_xfence_request(struct kvm *kvm, DECLARE_BITMAP(req_vcpu_mask, KVM_MAX_VCPUS); DECLARE_BITMAP(fallback_req_vcpu_mask, KVM_MAX_VCPUS); =20 + if (!data || !data->type) + return; + bitmap_zero(req_vcpu_mask, KVM_MAX_VCPUS); bitmap_zero(fallback_req_vcpu_mask, KVM_MAX_VCPUS); kvm_for_each_vcpu(i, vcpu, kvm) { @@ -346,11 +372,6 @@ static void make_xfence_request(struct kvm *kvm, continue; } =20 - if (!data || !data->type) { - bitmap_set(req_vcpu_mask, i, 1); - continue; - } - /* * Enqueue hfence data to VCPU hfence queue. If we don't * have space in the VCPU hfence queue then fallback to @@ -369,8 +390,7 @@ static void make_xfence_request(struct kvm *kvm, 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); + make_xfence_request_nodata(kvm, hbase, hmask, KVM_REQ_FENCE_I); } =20 void kvm_riscv_hfence_gvma_vmid_gpa(struct kvm *kvm, --=20 2.39.3