From patchwork Mon Mar 16 06:16:31 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Yechao X-Patchwork-Id: 2211154 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=3yNB3GHx; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4fZ4cG3vLcz1xy3 for ; Mon, 16 Mar 2026 17:16:46 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Mime-Version:Date: References:In-Reply-To:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=I9qKoTT/1vYdrOo+MCeZgWFrZVvkpqLCqj0PQzMjw2A=; b=3yNB3GHxy5iX05 BUzRyyiJxxC/L6q+5QAxCu7hmA7GeHI0xp3PmIQ805paSQakgyvdRpYufvrIwLMSE866NYU+a3K0G 38Bh8tuy1+ij7/wKqep6cSTFOiPAM2LhKummCo3ERIVCOOtDBzKZ2OXvXyT+sZxNXdkc1xAt9ewBy 2hdw8zJKcvzjGDsdYHQaCO4/imJ3Fh0oVg4NWwqEut9t7+sVYD7VPEa1BZwUKCzlxoX2KrBipUMSf LdAkeqjw1ltZ+dy5MxWqAwov76s476mK1aBICUMHmrtQE86WBLaVooObIZBYbwhJ3TGA9VzrKJJ37 rl0nbWAHqlOrrMZQXVBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w21Ft-00000003OmZ-16XW; Mon, 16 Mar 2026 06:16:45 +0000 Received: from mxhk.zte.com.cn ([160.30.148.34]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w21Fp-00000003OmC-3Lr5; Mon, 16 Mar 2026 06:16:43 +0000 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 4fZ4c70Mqxz4xPGS; Mon, 16 Mar 2026 14:16:39 +0800 (CST) Received: from szxl2zmapp07.zte.com.cn ([10.1.32.52]) by mse-fl2.zte.com.cn with SMTP id 62G6GTiv085875; Mon, 16 Mar 2026 14:16:29 +0800 (+08) (envelope-from wang.yechao255@zte.com.cn) Received: from mapi (szxl2zmapp06[null]) by mapi (Zmail) with MAPI id mid12; Mon, 16 Mar 2026 14:16:31 +0800 (CST) X-Zmail-TransId: 2b0869b7a03f5ae-1b7a0 X-Mailer: Zmail v1.0 Message-ID: <20260316141631543e3oVI3JGADhz5veSRD_eC@zte.com.cn> In-Reply-To: <20260316141234007qSAOsesu2cSQsj-LA-qq3@zte.com.cn> References: 20260316141234007qSAOsesu2cSQsj-LA-qq3@zte.com.cn Date: Mon, 16 Mar 2026 14:16:31 +0800 (CST) Mime-Version: 1.0 From: To: , , , , , Cc: , , , , , Subject: =?utf-8?q?=5BPATCH_v3_1/3=5D_RISC-V=3A_KVM=3A_Fix_lost_write_protec?= =?utf-8?q?tion_on_huge_pages_during_dirty_logging?= X-MAIL: mse-fl2.zte.com.cn 62G6GTiv085875 X-TLS: YES X-SPF-DOMAIN: zte.com.cn X-ENVELOPE-SENDER: wang.yechao255@zte.com.cn X-SPF: None X-SOURCE-IP: 10.5.228.133 unknown Mon, 16 Mar 2026 14:16:39 +0800 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 69B7A047.000/4fZ4c70Mqxz4xPGS X-Bad-Reply: References and In-Reply-To but no 'Re:' in Subject. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260315_231642_120781_93CC5C39 X-CRM114-Status: UNSURE ( 9.74 ) X-CRM114-Notice: Please train this message. X-Spam-Score: 0.2 (/) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: From: Wang Yechao When enabling dirty log in small chunks (e.g., QEMU default chunk size of 256K), the chunk size is always smaller than the page size of huge pages (1G or 2M) used in the gstage page tables. This cause [...] Content analysis details: (0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.8 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [160.30.148.34 listed in bl.score.senderscore.com] 0.9 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [160.30.148.34 listed in sa-accredit.habeas.com] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.4 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [160.30.148.34 listed in sa-trusted.bondedsender.org] X-BeenThere: kvm-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kvm-riscv" Errors-To: kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Wang Yechao When enabling dirty log in small chunks (e.g., QEMU default chunk size of 256K), the chunk size is always smaller than the page size of huge pages (1G or 2M) used in the gstage page tables. This caused the write protection to be incorrectly skipped for huge PTEs because the condition `(end - addr) >= page_size` was not satisfied. Remove the size check in `kvm_riscv_gstage_wp_range()` to ensure huge PTEs are always write-protected regardless of the chunk size. Additionally, explicitly align the address down to the page size before invoking `kvm_riscv_gstage_op_pte()` to guarantee that the address passed to the operation function is page-aligned. This fixes the issue where dirty pages might not be tracked correctly when using huge pages. Fixes: 9d05c1fee837 ("RISC-V: KVM: Implement stage2 page table programming") Signed-off-by: Wang Yechao Reviewed-by: Nutty Liu Reviewed-by: Anup Patel --- arch/riscv/kvm/gstage.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c index b67d60d722c2..d2001d508046 100644 --- a/arch/riscv/kvm/gstage.c +++ b/arch/riscv/kvm/gstage.c @@ -304,10 +304,9 @@ void kvm_riscv_gstage_wp_range(struct kvm_gstage *gstage, gpa_t start, gpa_t end if (!found_leaf) goto next; - if (!(addr & (page_size - 1)) && ((end - addr) >= page_size)) - kvm_riscv_gstage_op_pte(gstage, addr, ptep, - ptep_level, GSTAGE_OP_WP); - + addr = ALIGN_DOWN(addr, page_size); + kvm_riscv_gstage_op_pte(gstage, addr, ptep, + ptep_level, GSTAGE_OP_WP); next: addr += page_size; }