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; } From patchwork Mon Mar 16 06:18:36 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Yechao X-Patchwork-Id: 2211155 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=F4lfE+PX; 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 4fZ4fw6Wkfz1xy3 for ; Mon, 16 Mar 2026 17:19:04 +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=TluHd284UecwTe26BhtypPWbHAXeeuTKy6DxFjWpDKM=; b=F4lfE+PXo7V54A WloAK56eKCllIcgM4p/3cpyndfzFaPDdPLJj5Nzwj1NffV7G+Jtu++b9pt2Fi0xdlyPgmUfpobTiW 6IKbE/CzozBfPeeynul9TFp6iLXL+YxXMO1Ww2KpzGUimL85vSL0KDpdFMfjZNp1YjEhIvpHUbJCe CNMBZPSao5pZbvMQM3kCxCHx9Z489pBxVtGRA0TTIsDFWQfxRfKIfwHNDiQ567yMt8/VdUSZsZjFT WVGMEi1Y1uB3dJGVtWthUxt2eCicYxFaN3JOtrcp3ukKuBhZJPonrHcx5rtGHGKnsz2g/e9kMdI78 FMfa5/4zc1gu38prbEDA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w21I7-00000003PBS-1UmX; Mon, 16 Mar 2026 06:19:03 +0000 Received: from mxct.zte.com.cn ([183.62.165.209]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w21I3-00000003P9v-0aC2; Mon, 16 Mar 2026 06:19:00 +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 mxct.zte.com.cn (FangMail) with ESMTPS id 4fZ4fW6K72z4xQX9; Mon, 16 Mar 2026 14:18:43 +0800 (CST) Received: from szxl2zmapp07.zte.com.cn ([10.1.32.52]) by mse-fl2.zte.com.cn with SMTP id 62G6IZu4088164; Mon, 16 Mar 2026 14:18:35 +0800 (+08) (envelope-from wang.yechao255@zte.com.cn) Received: from mapi (szxlzmapp01[null]) by mapi (Zmail) with MAPI id mid12; Mon, 16 Mar 2026 14:18:36 +0800 (CST) X-Zmail-TransId: 2b0369b7a0bcfa0-2c182 X-Mailer: Zmail v1.0 Message-ID: <20260316141836922ffC0zmiE01ptC2jpXl4zJ@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:18:36 +0800 (CST) Mime-Version: 1.0 From: To: , , , , , Cc: , , , , Subject: =?utf-8?q?=5BPATCH_v3_2/3=5D_RISC-V=3A_KVM=3A_Allow_splitting_huge_?= =?utf-8?q?pages_to_arbitrary_level?= X-MAIL: mse-fl2.zte.com.cn 62G6IZu4088164 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:18:43 +0800 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 69B7A0C3.000/4fZ4fW6K72z4xQX9 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_231859_782455_74DD0B8E X-CRM114-Status: GOOD ( 13.57 ) X-Spam-Score: -2.1 (--) 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 This patch introduces the function kvm_riscv_gstage_split_huge(). It splits the huge page covering a given guest physical address down to a specified target level (e.g., from 1G to 2M or 4K). The call [...] Content analysis details: (-2.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [183.62.165.209 listed in list.dnswl.org] 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. [183.62.165.209 listed in sa-accredit.habeas.com] 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. [183.62.165.209 listed in sa-trusted.bondedsender.org] 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.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [183.62.165.209 listed in wl.mailspike.net] 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. [183.62.165.209 listed in bl.score.senderscore.com] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 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 This patch introduces the function kvm_riscv_gstage_split_huge(). It splits the huge page covering a given guest physical address down to a specified target level (e.g., from 1G to 2M or 4K). The caller provides a memory cache for allocating any intermediate page tables and may request a TLB flush after the split. This functionality will be used by subsequent patches to split huge pages before handling the write-protection fault, or for other operations that require page-level granularity. Signed-off-by: Wang Yechao --- arch/riscv/include/asm/kvm_gstage.h | 4 ++ arch/riscv/kvm/gstage.c | 69 +++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) diff --git a/arch/riscv/include/asm/kvm_gstage.h b/arch/riscv/include/asm/kvm_gstage.h index 595e2183173e..373748c6745e 100644 --- a/arch/riscv/include/asm/kvm_gstage.h +++ b/arch/riscv/include/asm/kvm_gstage.h @@ -53,6 +53,10 @@ int kvm_riscv_gstage_map_page(struct kvm_gstage *gstage, bool page_rdonly, bool page_exec, struct kvm_gstage_mapping *out_map); +int kvm_riscv_gstage_split_huge(struct kvm_gstage *gstage, + struct kvm_mmu_memory_cache *pcache, + gpa_t addr, u32 target_level, bool flush); + enum kvm_riscv_gstage_op { GSTAGE_OP_NOP = 0, /* Nothing */ GSTAGE_OP_CLEAR, /* Clear/Unmap */ diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c index d2001d508046..5356abb18932 100644 --- a/arch/riscv/kvm/gstage.c +++ b/arch/riscv/kvm/gstage.c @@ -209,6 +209,75 @@ int kvm_riscv_gstage_map_page(struct kvm_gstage *gstage, return kvm_riscv_gstage_set_pte(gstage, pcache, out_map); } +static inline unsigned long make_child_pte(unsigned long huge_pte, int index, + unsigned long child_page_size) +{ + unsigned long child_pte = huge_pte; + unsigned long child_pfn_offset; + + /* + * The child_pte already has the base address of the huge page being + * split. So we just have to OR in the offset to the page at the next + * lower level for the given index. + */ + child_pfn_offset = index * (child_page_size / PAGE_SIZE); + child_pte |= pte_val(pfn_pte(child_pfn_offset, __pgprot(0))); + + return child_pte; +} + +int kvm_riscv_gstage_split_huge(struct kvm_gstage *gstage, + struct kvm_mmu_memory_cache *pcache, + gpa_t addr, u32 target_level, bool flush) +{ + u32 current_level = kvm_riscv_gstage_pgd_levels - 1; + pte_t *next_ptep = (pte_t *)gstage->pgd; + pte_t *ptep; + unsigned long huge_pte, child_pte; + unsigned long child_page_size; + int i, ret; + + while(current_level > target_level) { + ptep = (pte_t *)&next_ptep[gstage_pte_index(addr, current_level)]; + + if (!pte_val(ptep_get(ptep))) + break; + + if (!gstage_pte_leaf(ptep)) { + next_ptep = (pte_t *)gstage_pte_page_vaddr(ptep_get(ptep)); + current_level--; + continue; + } + + huge_pte = pte_val(ptep_get(ptep)); + + ret = gstage_level_to_page_size(current_level - 1, &child_page_size); + if (ret) + return ret; + + if (!pcache) + return -ENOMEM; + next_ptep = kvm_mmu_memory_cache_alloc(pcache); + if (!next_ptep) + return -ENOMEM; + + for (i = 0; i < PTRS_PER_PTE; i++) { + child_pte = make_child_pte(huge_pte, i, child_page_size); + set_pte((pte_t *)&next_ptep[i], __pte(child_pte)); + } + + set_pte(ptep, pfn_pte(PFN_DOWN(__pa(next_ptep)), + __pgprot(_PAGE_TABLE))); + + if (flush) + gstage_tlb_flush(gstage, current_level, addr); + + current_level--; + } + + return 0; +} + void kvm_riscv_gstage_op_pte(struct kvm_gstage *gstage, gpa_t addr, pte_t *ptep, u32 ptep_level, enum kvm_riscv_gstage_op op) { From patchwork Mon Mar 16 06:20:17 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Yechao X-Patchwork-Id: 2211156 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=HhFgRv5/; 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 4fZ4hn1Zvlz1xqn for ; Mon, 16 Mar 2026 17:20:41 +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=lp+mgsLTIvR3TZN6tZRdK4JI16qez9bUOi5rB/BhXwY=; b=HhFgRv5/KJT1Ub p/k2BuRhz0CH4zGFPymPV5WBklhb9wHFBDDWMboeiAJT3l86pwbgL46GIEDP14Dv9IC0d/ITgMzov JOrYfz+32BYJhWN+FdgpdEgEFymkaY/8k0VZUbNd8RR/t3xevylblixSwRLM7J4mjF50M4aHAds4G EgGkhwReNoRakOyMNDonUlNt55Y5Z2hltGrGHtVWIthuIko4KX1y8dJkp/aZoCfYNDdIBAdq8Tnwc P4kbmjjdcbvoHjMQRz1J4pdKqHIWpQ8PKVwXY2E18V6MjjBplOoF2SLixmGvthsP7wQvzQ2rdjxAv N3ehDN/3m15q2uAgAUvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w21Jg-00000003PGN-09Y5; Mon, 16 Mar 2026 06:20:40 +0000 Received: from mxct.zte.com.cn ([183.62.165.209]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w21Jd-00000003PFy-1pjU; Mon, 16 Mar 2026 06:20:38 +0000 Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (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 mxct.zte.com.cn (FangMail) with ESMTPS id 4fZ4hc4nwkz51Sdl; Mon, 16 Mar 2026 14:20:32 +0800 (CST) Received: from szxl2zmapp05.zte.com.cn ([10.1.32.37]) by mse-fl1.zte.com.cn with SMTP id 62G6KF36004235; Mon, 16 Mar 2026 14:20:15 +0800 (+08) (envelope-from wang.yechao255@zte.com.cn) Received: from mapi (szxlzmapp04[null]) by mapi (Zmail) with MAPI id mid12; Mon, 16 Mar 2026 14:20:17 +0800 (CST) X-Zmail-TransId: 2b0669b7a121451-2263c X-Mailer: Zmail v1.0 Message-ID: <20260316142017362R7MOT-xQWGMPiGnD0zuht@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:20:17 +0800 (CST) Mime-Version: 1.0 From: To: , , , , , Cc: , , , , Subject: =?utf-8?q?=5BPATCH_v3_3/3=5D_RISC-V=3A_KVM=3A_Split_huge_pages_duri?= =?utf-8?q?ng_fault_handling_for_dirty_logging?= X-MAIL: mse-fl1.zte.com.cn 62G6KF36004235 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.132 unknown Mon, 16 Mar 2026 14:20:32 +0800 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 69B7A130.002/4fZ4hc4nwkz51Sdl 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_232037_638785_442DF398 X-CRM114-Status: GOOD ( 15.67 ) X-Spam-Score: -2.1 (--) 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 During dirty logging, all huge pages are write-protected. When the guest writes to a write-protected huge page, a page fault is triggered. Before recovering the write permission, the huge page must be [...] Content analysis details: (-2.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [183.62.165.209 listed in list.dnswl.org] 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.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. [183.62.165.209 listed in sa-accredit.habeas.com] 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. [183.62.165.209 listed in sa-trusted.bondedsender.org] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [183.62.165.209 listed in wl.mailspike.net] 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. [183.62.165.209 listed in bl.score.senderscore.com] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 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 During dirty logging, all huge pages are write-protected. When the guest writes to a write-protected huge page, a page fault is triggered. Before recovering the write permission, the huge page must be split into smaller pages (e.g., 4K). After splitting, the normal mapping process proceeds, allowing write permission to be restored at the smaller page granularity. If dirty logging is disabled because migration failed or was cancelled, only recover the write permission at the 4K level, and skip recovering the huge page mapping at this time to avoid the overhead of freeing page tables. The huge page mapping can be recovered in the ioctl context, similar to x86, in a later patch. Signed-off-by: Wang Yechao --- arch/riscv/kvm/gstage.c | 56 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c index 5356abb18932..4bee042f3c7f 100644 --- a/arch/riscv/kvm/gstage.c +++ b/arch/riscv/kvm/gstage.c @@ -163,6 +163,21 @@ int kvm_riscv_gstage_set_pte(struct kvm_gstage *gstage, return 0; } +static int kvm_riscv_gstage_update_pte_prot(pte_t *ptep, pgprot_t prot) +{ + pte_t new_pte; + + if (pgprot_val(pte_pgprot(ptep_get(ptep))) == pgprot_val(prot)) + return 0; + + new_pte = pfn_pte(pte_pfn(ptep_get(ptep)), prot); + new_pte = pte_mkdirty(new_pte); + + set_pte(ptep, new_pte); + + return 1; +} + int kvm_riscv_gstage_map_page(struct kvm_gstage *gstage, struct kvm_mmu_memory_cache *pcache, gpa_t gpa, phys_addr_t hpa, unsigned long page_size, @@ -171,6 +186,9 @@ int kvm_riscv_gstage_map_page(struct kvm_gstage *gstage, { pgprot_t prot; int ret; + pte_t *ptep; + u32 ptep_level; + bool found_leaf; out_map->addr = gpa; out_map->level = 0; @@ -203,6 +221,44 @@ int kvm_riscv_gstage_map_page(struct kvm_gstage *gstage, else prot = PAGE_WRITE; } + + found_leaf = kvm_riscv_gstage_get_leaf(gstage, gpa, &ptep, &ptep_level); + if (found_leaf) { + /* + * ptep_level is the current gstage mapping level of addr, out_map->level + * is the required mapping level during fault handling. + * + * 1) ptep_level > out_map->level + * This happens when dirty logging is enabled and huge pages are used. + * KVM must track the pages at 4K level, and split the huge mapping + * into 4K mappings. + * + * 2) ptep_level < out_map->level + * This happens when dirty logging is disabled and huge pages are used. + * The gstage is split into 4K mappings, but the out_map level is now + * back to the huge page level. Ignore the out_map level this time, and + * just update the pte prot here. Otherwise, we would fall back to mapping + * the gstage at huge page level in `kvm_riscv_gstage_set_pte`, with the + * overhead of freeing the page tables(not support now), which would slow + * down the vCPUs' performance. + * + * It is better to recover the huge page mapping in the ioctl context when + * disabling dirty logging. + * + * 3) ptep_level == out_map->level + * We already have the ptep, just update the pte prot if the pfn not change. + * There is no need to invoke `kvm_riscv_gstage_set_pte` again. + */ + if (ptep_level > out_map->level) { + kvm_riscv_gstage_split_huge(gstage, pcache, gpa, + out_map->level, true); + } else if (ALIGN_DOWN(PFN_PHYS(pte_pfn(ptep_get(ptep))), page_size) == hpa) { + if (kvm_riscv_gstage_update_pte_prot(ptep, prot)) + gstage_tlb_flush(gstage, ptep_level, out_map->addr); + return 0; + } + } + out_map->pte = pfn_pte(PFN_DOWN(hpa), prot); out_map->pte = pte_mkdirty(out_map->pte);