From nobody Thu Sep 24 20:24:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1789032920; cv=none; d=zohomail.com; s=zohoarc; b=fixxWz0VgKpPBYPGokFqaQodLyL5EAJdK546DPcXc8h8mnn0Pwq2LJREBkFaFjPrHtwz/TRDRiOscDMtQguxtWr5RPBM1XbAlrEXwbNiAklUywGB95BVrd4SXWx9bypUMKcY6BqCE8yveAQ0i3voDrFplvP5Jgk5DIdFLMFB1MM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789032920; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=gYWVowcg1/XIljyI4nY8iK28MBBdYrH7NMXkWVSNpfM=; b=E7xJJBiGx2Z9l1A7c0O0f490PYJMT9j/Zqw701P88ABr4+TGa20bfRZWAp6MwDfVzV23xSxGCiEppksFsoIwfBKHSctoHRkh3PEX3dPXCQEHbdaGSQCsE1p9NlGTk6GjDDGOZGLpkdBuV7ArxfeGL8aKTZWHk93B28MeVyA7704= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1789032920831292.83676857976616; Thu, 10 Sep 2026 02:35:20 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1414227.1644001 (Exim 4.92) (envelope-from ) id 1x4bBN-0003A0-UW; Thu, 10 Sep 2026 09:35:01 +0000 Received: by outflank-mailman (output) from mailman id 1414227.1644001; Thu, 10 Sep 2026 09:35:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBN-00039t-QO; Thu, 10 Sep 2026 09:35:01 +0000 Received: by outflank-mailman (input) for mailman id 1414227; Thu, 10 Sep 2026 09:35:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBM-00039m-30 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBL-007nqx-Fy for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:34:59 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279bd-8faa-0a2a0a5109dd-0a2a4502cc62-22 for ; Thu, 10 Sep 2026 11:34:59 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279c3-6ca4-0a2a45020019-b9ff1c23b5c1-3 for ; Thu, 10 Sep 2026 11:34:59 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aab9d76000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:57 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 3373E81DDF; Thu, 10 Sep 2026 11:34:57 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=gYWVowcg1/XIljyI4nY8iK28MBBdYrH7NMXkWVSNpfM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=sTiR6FgdvGnCzho+hwFBWWNTxCNMZavPQLPoiXrUorI83SUmBEeVjdpzI4tFBPnkPPkDFtRbw qi2/biOF69sDiFNgiEf0sDL6idkS1NbnyYn8LpgOJ075O2IR5la1LUS2vCJuHQTg9msnWdhF6qO 1yYUL1cWgCaVUjAAQwIiAw89EHD2gaIxSMYadeFFcR+Shw/OSoHnBgIQqJ21l53XOXho0drjFMt K2vI0qbbxwVLcci8X0q4fCu5HyuaMNrUhgxNAWI/UT+fECgnURQ3dO06kwClPzeferFUrNXzsLy RpAO43oae5+DlT7x8LPOhzipeQ2lesjh2sQK6NBGRvUA== X-Zone-Loop: 500b563be99b06f20e9ebef69834de1db2119f884266 x-campaign-type: default x-transaction-id: 60bd194f-56ef-4de6-9b44-6482c5c4eda9 x-swg-uid: 01-0624438b-142b-4702-b68e-5c575101639d X-Mailer: Sweego Message-ID: <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> x-swg-bid: 1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling Date: Thu, 10 Sep 2026 11:34:49 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=10641; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=O+TAA7wrcm6AfiwPOIR/C5+ZEMAyiEayDxvF+dXKij4=; b=OBLZp0zMgkk12Yg/gEuepBjWKf+LHBW3gB7JCv2AO4uChiyS8U4eqLm1A0SZ5UmNBakPr67/z 2q0QUiAHQyGCGr1JLUCw23KK7UnDeig4i1JM2tDy7D2zTG5TPWPxKN6 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032897403 X-purgate-ID: tlsNG-720697/1789032899-668B42AC-2613E51E/0/0 X-purgate-type: clean X-purgate-size: 10643 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1789032923236158500 p2m_set_permission() only presets the PTE A/D bits when the Svade extension is present in the device tree. This causes an unhandled page fault when neither Svade nor Svadu is present (the platform's actual behaviour is then unknown), and when both are present in the device tree. Move the Svade/Svadu resolution out of p2m_set_permission() and into a new riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of the four possible Svade/Svadu combinations (inspired by [1]), it decides whether software has to preset the A/D bits and, if so, sets RISCV_ISA_EXT_svade to record that decision: - neither present: assume Svade, since assuming Svade is harmless on real Svadu hardware, while assuming Svadu on real Svade hardware risks an unhandled page fault - only Svade present: assume Svade - only Svadu present: leave A/D management to hardware - both present: Svade wins until Xen supports the SBI FWFT call needed to enable hardware updating of A/D bits, so assume Svade and warn that dropping 'svade' from the DT is the only way to get Svadu. [1] https://lwn.net/Articles/980016/ Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support P= BMT configuration") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - change commit title - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). - expose sbi_probe_extension() (was static) to probe for SBI FWFT. - stop presetting A/D bits unconditionally in p2m_set_permission(), do it only when Svade is present. --- xen/arch/riscv/cpufeature.c | 59 +++++++++++++++++++++++++++++= ++++ xen/arch/riscv/include/asm/cpufeature.h | 1 + xen/arch/riscv/include/asm/sbi.h | 8 +++++ xen/arch/riscv/p2m.c | 47 ++++++++++---------------- 4 files changed, 86 insertions(+), 29 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 92235fdfd5..19454544a7 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -18,6 +18,7 @@ =20 #include #include +#include =20 #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) return false; } =20 +/* + * Svade and Svadu extensions represent two schemes for managing the PTE A= /D + * bits. When the PTE A/D bits need to be set, the Svade extension indicat= es + * that a page fault will be raised. In contrast, the Svadu extension supp= orts + * hardware updating of the PTE A/D bits. + * + * There are 4 possible combinations of these extensions in the device tre= e. + * The default hardware behavior for each is: + * + * 1) Neither Svade nor Svadu present in DT =3D> It is technically unknown + * whether the platform uses Svade or Svadu. Xen should be prepared to + * handle either hardware updating of the PTE A/D bits or page faults w= hen + * they need updating. In that case, Xen assumes Svade because it's + * harmless if the platform is actually Svadu, while assuming Svadu on = real + * Svade hardware risks an unhandled page fault. + * + * 2) Only Svade present in DT =3D> Xen must assume Svade to be always ena= bled. + * + * 3) Only Svadu present in DT =3D> Xen must assume Svadu to be always ena= bled. + * + * 4) Both Svade and Svadu present in DT =3D> Xen must assume Svadu is tur= ned off + * at boot time by setting A/D bits. To use Svadu, the supervisor must + * explicitly enable it using the SBI FWFT extension. + * + * The Svade extension is mandatory and the Svadu extension is optional in= the + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose + * option 3. Platforms aware of the profile can choose option 4, and Xen w= on't + * get the benefit of Svadu until the SBI FWFT extension is available. + * + * In other words, hardware manages the A/D bits on its own only in case 3= , in + * all the other cases software has to preset them. Instead of open coding= this + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. + */ +static void __init riscv_resolve_ad_scheme(void) +{ + bool svade =3D riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade= ); + bool svadu =3D riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu= ); + + /* Case 3: leave the A/D bits management to hardware. */ + if ( svadu && !svade ) + return; + + /* Case 4 */ + if ( svadu && svade ){ + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, bu= t SBI FWFT is missing.\n" + "RISC-V: Defaulting to software A/D updates (Svade).\n" + "RISC-V: To force hardware A/D updates (Svadu), remove '= svade' from DT.\n"); + } + } + + /* Cases 1, 2: Xen assume Svade to be enabled */ + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); +} + bool riscv_isa_extension_available(const unsigned long *isa_bitmap, enum riscv_isa_ext_id id) { @@ -513,6 +570,8 @@ void __init riscv_fill_hwcap(void) __set_bit(RISCV_ISA_EXT_sstc, riscv_isa); } =20 + riscv_resolve_ad_scheme(); + for ( i =3D 0; i < req_extns_amount; i++ ) { const struct riscv_isa_ext_data ext =3D required_extensions[i]; diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/inclu= de/asm/cpufeature.h index 0c48d57a03..74200ce7c9 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, RISCV_ISA_EXT_svpbmt, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_MAX }; =20 diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/= sbi.h index 1952868e96..4f13e8c7a0 100644 --- a/xen/arch/riscv/include/asm/sbi.h +++ b/xen/arch/riscv/include/asm/sbi.h @@ -30,6 +30,7 @@ #define SBI_EXT_BASE 0x10 #define SBI_EXT_RFENCE 0x52464E43 #define SBI_EXT_TIME 0x54494D45 +#define SBI_EXT_FWFT 0x46574654 =20 /* SBI function IDs for BASE extension */ #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 @@ -138,6 +139,13 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, = vaddr_t start, int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, size_t size, unsigned long vmid); =20 +/** + * Check if an SBI extension ID is supported or not. + * @extid: The extension ID to be probed. + * + * @return: 1 or an extension specific nonzero value if yes, 0 otherwise. + */ +int sbi_probe_extension(long extid); /* * Initialize SBI library * diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 1cea86512c..22ad4a2aee 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -586,42 +586,31 @@ static inline void p2m_clean_pte(pte_t *p, bool clean= _cache) =20 static void p2m_set_permission(pte_t *e, p2m_type_t t) { + bool svade =3D riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade= ); + bool svadu =3D riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu= ); + e->pte &=3D ~PTE_ACCESS_MASK; =20 e->pte |=3D PTE_USER; =20 /* - * Two schemes to manage the A and D bits are defined: - * =E2=80=A2 The Svade extension: when a virtual page is accessed an= d the A bit - * is clear, or is written and the D bit is clear, a page-fault - * exception is raised. - * =E2=80=A2 When the Svade extension is not implemented, the follow= ing scheme - * applies. - * When a virtual page is accessed and the A bit is clear, the PTE= is - * updated to set the A bit. When the virtual page is written and = the - * D bit is clear, the PTE is updated to set the D bit. When G-sta= ge - * address translation is in use and is not Bare, the G-stage virt= ual - * pages may be accessed or written by implicit accesses to VS-lev= el - * memory management data structures, such as page tables. - * Thereby to avoid a page-fault in case of Svade is available, it is - * necessary to set A and D bits. - * - * TODO: For now, it=E2=80=99s fine to simply set the A/D bits, since = OpenSBI - * delegates page faults to a lower privilege mode and so OpenSBI - * isn't expect to handle page-faults occured in lower modes. - * By setting the A/D bits here, page faults that would otherwise - * be generated due to unset A/D bits will not occur in Xen. - * - * Currently, Xen on RISC-V does not make use of the information - * that could be obtained from handling such page faults, which - * could otherwise be useful for several use cases such as demand - * paging, cache-flushing optimizations, memory access tracking,= etc. + * riscv_fill_hwcap() sets either RISCV_ISA_EXT_svade or + * RISCV_ISA_EXT_svadu (mutually exclusive) depending on the Svade/Sva= du + * device tree combination (see riscv_resolve_ad_scheme()): + * - RISCV_ISA_EXT_svade means that software is responsible for the A/D + * bits. + * - RISCV_ISA_EXT_svadu means the hardware is responsible for the A/D + * bits. * - * To support the more general case and the optimizations mentio= ned - * above, it would be better to stop setting the A/D bits here a= nd - * instead handle page faults that occur due to unset A/D bits. + * Currently, when RISCV_ISA_EXT_svade is set, Xen doesn't track A/D + * bits, so it does not make use of the information that could be + * obtained from handling the resulting page faults, which could + * otherwise be useful for several use cases such as demand paging, + * cache-flushing optimizations, memory access tracking, etc. To avoid + * such a page fault, Xen presets the A and D bits instead. */ - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) + ASSERT(svade !=3D svadu); /* exactly one of svade/svadu must be set by= riscv_fill_hwcap() */ + if ( svade ) e->pte |=3D PTE_ACCESSED | PTE_DIRTY; =20 switch ( t ) --=20 2.55.0 From nobody Thu Sep 24 20:24:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1789032924; cv=none; d=zohomail.com; s=zohoarc; b=OhV0f7depKgyg2m1jzde5ZoJ1qIYwaiMtwY6/jC6AwCIi3TwPYqsapCe0k/bWvj572cYay6jnQihEhPLk/9rg7BpaBQ+G8GO5HQGLZcw2LeSqnDmhfkwMqBOQLDOJf2DOjeVURPwj1clf7e1KhyNn5QBL+Mkm4HOMjrGO+crhUc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789032924; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=OQMa161a+Wta8D11iB/ndQm1se8KfDbFH6WIHdvaHGI=; b=IsmBja6rRo/Kyv2JcU0/WiHaarqjI0kQa2KFAahIh/ynBZ+c8GjpYTm/W2tEF6XWfKY8WfzD2HhMZ1VQQlJMjT9KmktxpKuaTTc6h2kJUHtIg2d6PNREUehgaBE1Bp6WJ2aZgOiViBpSaw/0OvFlmSGhB5ZnS9P/t3pPEFvTrDA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 17890329247941003.6401455382581; Thu, 10 Sep 2026 02:35:24 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1414228.1644009 (Exim 4.92) (envelope-from ) id 1x4bBQ-0003Ml-4M; Thu, 10 Sep 2026 09:35:04 +0000 Received: by outflank-mailman (output) from mailman id 1414228.1644009; Thu, 10 Sep 2026 09:35:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBQ-0003Me-11; Thu, 10 Sep 2026 09:35:04 +0000 Received: by outflank-mailman (input) for mailman id 1414228; Thu, 10 Sep 2026 09:35:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBO-0003Kb-Rc for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBO-007nqx-8P for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:02 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279bd-8faa-0a2a0a5109dd-0a2a4502cc62-34 for ; Thu, 10 Sep 2026 11:35:02 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279c3-6ca4-0a2a45020019-b9ff1c23b5c1-4 for ; Thu, 10 Sep 2026 11:35:02 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aab9ea7000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:58 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 8FCB681E02; Thu, 10 Sep 2026 11:34:57 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=OQMa161a+Wta8D11iB/ndQm1se8KfDbFH6WIHdvaHGI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=cWCdmEszRBcC73GGCImq8qDcfqxOmDvHgI6m4jSxSdHq2O9T8j15VYmlPKQZ2/NsFkkvCx+a6 d0IyGfjCK4F+Qe7A1/iiAvjogboos/uESXFDF1K+5x2kocxbetN71mdAVctcnypbOMp4xIGpeQL HeraKIcSHVw93MyJW9FA/TO+2EEnmu0k/KPtdHHnGrWee8RXZWRIc3Gs1/7b+iqD55TmkujTN/V YuIa70Qw4+vnF5wkqlyekiClYKYNPwhBlNsOyJ6AM2BXDY0bTw8PLVFBgsPSPW41uEhpUl2SDY8 /TKpzcVi9oKncoOr045sd0y2cChLQYuJlbiGhGAyy7TQ== X-Zone-Loop: a778dacaedad8c10749e69f932d7b5b69dfed1b74b21 x-campaign-type: default x-transaction-id: 4ea3cbea-497b-4bbe-8884-f42ffaf428a8 x-swg-uid: 01-05164e3a-3a95-4fc3-8b65-84eac62a50bc X-Mailer: Sweego Message-ID: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> x-swg-bid: 1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 2/6] xen/riscv: set A/D bits in Xen's page-table mappings under Svade Date: Thu, 10 Sep 2026 11:34:50 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=5833; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=oru9y8klMzu0KQzmHiXjBGBZGoTU/bzItz+YJ4+V2kI=; b=aqJBmtx9lgcJ1XkvpeN6/IaSMIUP8hMfW5EQpERjH0bEvJa7oau9woD2G/ciY+RXwX1d+Hn1/ jYG7W1NW7bHDlMaBvBSpjurL2Svy54ID5y9f75bQHcwIDOjGAjUshUJ X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032897774 X-purgate-ID: tlsNG-720697/1789032902-678BC2AC-0AED1F10/0/0 X-purgate-type: clean X-purgate-size: 5835 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1789032926920158500 The previous patch set A/D bits in case of the Svade extension for G-stage mappings. Xen's own S-stage mappings need the same fix as both setup_initial_mapping() (the boot page tables) and arch_pmap_map() (the fixmap) build leaf PTEs directly instead of going through pt_update_entry(), which is what adds A/D bits. So with Svade, both would fault on first access. Add PTE_ACCESSED to all PAGE_HYPERVISOR_* and also PTE_DIRTY to PAGE_HYPERVISOR_RW as it needs to be set during a write to avoid a fault. This fixes arch_pmap_map() for free, since it already builds its PTE from PAGE_HYPERVISOR_RW. Switch setup_initial_mapping() to use these macros for its default, text and rodata permissions, and for the temporary root entry built by check_pgtbl_mode_support(), instead of the equivalent raw bit lists. The latter drops PTE_WRITABLE, going from RWX to RX, but this is harmless, as that entry only has to make the current instruction stream fetchable between the two CSR_SATP writes used to probe SATP mode support, and nothing writes through it. Drop the now-redundant PTE_LEAF_DEFAULT, since converting the last open-coded site above leaves it with no user outside page.h itself. A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so update pte_is_table() and pte_is_mapping() accordingly. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Tested-by: Zheng Zhang --- Changes since v1: - change commit title - mention in patch message that arch_pmap_map() is fixed too, via the PAGE_HYPERVISOR_RW change, not just setup_initial_mapping(). - convert check_pgtbl_mode_support()'s temporary root entry to PAGE_HYPERVISOR_RX, as it's harmless. - drop PTE_LEAF_DEFAULT entirely instead of keeping it, now that no site open-codes it anymore. - drop the pte_is_table() comment line that referenced PAGE_HYPERVISOR_RW, now stale. --- xen/arch/riscv/include/asm/page.h | 15 +++++++-------- xen/arch/riscv/mm.c | 9 ++++----- 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm= /page.h index b465a90325..1977634efc 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,11 @@ #define PTE_PBMT_NOCACHE BIT(61, UL) #define PTE_PBMT_IO BIT(62, UL) =20 -#define PTE_LEAF_DEFAULT (PTE_VALID | PTE_READABLE | PTE_WRITAB= LE) #define PTE_TABLE (PTE_VALID) =20 -#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE) -#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITAB= LE) -#define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUT= ABLE) +#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE | PTE_ACCESS= ED) +#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITAB= LE | PTE_ACCESSED | PTE_DIRTY) +#define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUT= ABLE | PTE_ACCESSED) =20 #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -174,10 +173,9 @@ static inline bool pte_is_table(pte_t p) * According to the spec if V=3D1 and W=3D1 then R also needs to be 1 = as * R =3D 0 is reserved for future use ( look at the Table 4.5 ) so che= ck * in ASSERT that if (V=3D=3D1 && W=3D=3D1) then R isn't 0. - * - * PAGE_HYPERVISOR_RW contains PTE_VALID too. */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) !=3D (PTE_VALID | PTE_WRITABLE))); + ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=3D + (PTE_VALID | PTE_WRITABLE)); =20 return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) =3D=3D PTE_VALID); } @@ -185,7 +183,8 @@ static inline bool pte_is_table(pte_t p) static inline bool pte_is_mapping(pte_t p) { /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) !=3D (PTE_VALID | PTE_WRITABLE))); + ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=3D + (PTE_VALID | PTE_WRITABLE)); =20 return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); } diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 4d3b8c2204..53bebbcabf 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,7 +140,7 @@ static void __init setup_initial_mapping(struct mmu_des= c *mmu_desc, case 1: /* Level 0 */ { unsigned long paddr =3D (page_addr - map_start) + pa_start; - unsigned int permissions =3D PTE_LEAF_DEFAULT; + unsigned int permissions =3D PAGE_HYPERVISOR_RW; unsigned long addr =3D is_identity_mapping ? page_addr : virt_to_maddr(page_addr= ); pte_t pte_to_be_written; @@ -149,11 +149,10 @@ static void __init setup_initial_mapping(struct mmu_d= esc *mmu_desc, =20 if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) - permissions =3D - PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + permissions =3D PAGE_HYPERVISOR_RX; =20 if ( is_kernel_rodata(addr) ) - permissions =3D PTE_READABLE | PTE_VALID; + permissions =3D PAGE_HYPERVISOR_RO; =20 pte_to_be_written =3D paddr_to_pte(paddr, permissions); =20 @@ -198,7 +197,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_= desc *mmu_desc, =20 index =3D pt_index(page_table_level, aligned_load_start); stage1_pgtbl_root[index] =3D paddr_to_pte(aligned_load_start, - PTE_LEAF_DEFAULT | PTE_EXECUTA= BLE); + PAGE_HYPERVISOR_RX); =20 sfence_vma(); csr_write(CSR_SATP, --=20 2.55.0 From nobody Thu Sep 24 20:24:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1789032930; cv=none; d=zohomail.com; s=zohoarc; b=gBFRhxiRdiHIuyiKkjnp6S6P+s78c2EBcSM4kuMjdwyHzbS61TuOoH6Wvr1ZnWgrN2EmUJKhBZFQLPOgquthFdzGbP/TDef51JMPjP3hfmNLI9qzyOVsq3w5X7b1ejWgMxMB+3IGmCr+ovoO9iUR4ZnZ5Sy3WBlhB3k9+HCX3qQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789032930; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=y+IsxIUnoTJ7eAPggcrJIaoVT6eUFG1bxyCAiLEuHMg=; b=XiE6lIYn+WfRe/URfsWGIl1HVb0X2oDJPKyhzr4DgiFg2x6K1kKjiGRwLktZuPyaXq7IdLfJR+sB+oknwJoOXyNubPUwgCr1HZh3L6eWFepXS72qFa0Puf2YdCQ8hjSnh6ljHURLir6u50n1fpaitSNBOzcV7UF6goq6DP/R5Ek= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1789032929871472.1963663053498; Thu, 10 Sep 2026 02:35:29 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1414229.1644018 (Exim 4.92) (envelope-from ) id 1x4bBW-0003do-FJ; Thu, 10 Sep 2026 09:35:10 +0000 Received: by outflank-mailman (output) from mailman id 1414229.1644018; Thu, 10 Sep 2026 09:35:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBW-0003dh-C6; Thu, 10 Sep 2026 09:35:10 +0000 Received: by outflank-mailman (input) for mailman id 1414229; Thu, 10 Sep 2026 09:35:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBU-0003cL-TQ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBU-00G7oY-A2 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279bd-8faa-0a2a0a5109dd-0a2a4502cc62-48 for ; Thu, 10 Sep 2026 11:35:08 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279cb-6ca4-0a2a45020019-b9ff1c22b70b-3 for ; Thu, 10 Sep 2026 11:35:08 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aab9fe1000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:58 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E19E581E0F; Thu, 10 Sep 2026 11:34:57 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=y+IsxIUnoTJ7eAPggcrJIaoVT6eUFG1bxyCAiLEuHMg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=mVEoV+cdWmYpo0yN2PoFoFm6su5rVz9xmpjr2yWvBwTfeGCwU96zUfmc9E0dv31V+3n0L6SqX +PWI9+HXQzGFqDsxOYcO4Z820DzupzKK5U5dCg8Fj5W8E+ZSYamWl759jj7I3JAWrBsEqChpI1t 1s9GuejpFOvyLtUH7lA4JYTbw4IMYhVc2jnCWOuC3xuEphcxH1HTkT8m/cEgAxrNnF0NNsk8FVo MXaho4VsObjRpr2I+H0IMjeVx6Bs1XhFSW/5qYizoZa5mJqK5L/nVP6glqHXIFrgQ22HwTgAyhy Jz8lJAu568BFdwK9rwxaD7KZY0ufZ8U0a7HQ1HxIMFrQ== X-Zone-Loop: fed367620279910bd4afbcd0f0efd652e782570c53d3 x-campaign-type: default x-transaction-id: df48f6a2-9f66-4e4c-a685-0a9b35d69214 x-swg-uid: 01-a095095e-5f1b-4da2-8e07-b164421b7cdd X-Mailer: Sweego Message-ID: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> x-swg-bid: 1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension Date: Thu, 10 Sep 2026 11:34:51 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=6794; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=jrynfzaXIgAgy7hsDbMYdbj40qrjRkErilQHWPhMvw4=; b=jL58PSCbRDoyd13ZmmFspDh5pZCqXjOmrh0K13a6ZPVkYgmY5IWP9x+fS03FnnxWULDTx4l7h Y8s8jl0vBxBBVXMlCqdTfn2fFLY9fQANeduvMqcWWxF/HvFFkatZITX X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032898104 X-purgate-ID: tlsNG-720697/1789032908-F2EB32AC-725EF78D/0/0 X-purgate-type: clean X-purgate-size: 6796 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1789032931051158501 Without the Svpbmt extension, memory attributes (such as cacheability and ordering) are strictly tied to physical address ranges and enforced by the hardware's Physical Memory Attributes (PMA) checker. In this configuration, supervisor software relies on the platform's memory map: - peripheral device registers (MMIO) are physically mapped into hardware-defined I/O regions (which are implicitly non-cacheable and strongly-ordered) - regular RAM is mapped as cacheable main memory. S-mode paging can safely map these physical ranges without specifying page-based memory types in the PTEs, as the hardware MMU and PMA pipeline will correctly bypass caches for MMIO accesses and use caches for RAM accesses, based on the target physical address. Furthermore, on platforms that either feature fully hardware-coherent DMA or don't expose non-coherent DMA agents to the OS, page-level programmatic cache control via Svpbmt is not required, making it safe to boot and run when Svpbmt is absent. Drop Svpbmt from required_extensions. Introduce svpbmt_enabled, a __ro_after_init flag computed once in init_csr_masks() from ISA availability and the henvcfg.PBMTE bit. Xen cannot read menvcfg.PBMTE directly, since menvcfg is M-mode-only and unreadable from HS-mode, but the spec guarantees henvcfg.PBMTE reads as zero whenever menvcfg.PBMTE is zero, so checking henvcfg.PBMTE alone is sufficient. Use svpbmt_enabled in pte_pbmt_nocache()/pte_pbmt_io(), two new inline helpers that mask the PBMT encoding down to 0 when Svpbmt is unavailable. Also switch vcpu_csr_init() branch to determine if Svpbmt was enabled to svpbmt_enabled as it does the same logic. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - Replace the pte_pbmt() macro, which re-checked riscv_isa_extension_available() on every call, with a svpbmt_enabled flag cached once in init_csr_masks(). - Add pte_pbmt_nocache()/pte_pbmt_io() inline helpers instead, used by PAGE_HYPERVISOR_NOCACHE/WC and p2m_pte_from_mfn(). - Switch vcpu_csr_init() to the same cached svpbmt_enabled flag instead of re-deriving Svpbmt availability itself. --- xen/arch/riscv/cpufeature.c | 1 - xen/arch/riscv/domain.c | 10 ++++++++-- xen/arch/riscv/include/asm/page.h | 22 +++++++++++++++++++--- xen/arch/riscv/p2m.c | 2 +- 4 files changed, 28 insertions(+), 7 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 19454544a7..986a6dec78 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -158,7 +158,6 @@ static const struct riscv_isa_ext_data __initconst requ= ired_extensions[] =3D { RISCV_ISA_EXT_DATA(zifencei), RISCV_ISA_EXT_DATA(zihintpause), RISCV_ISA_EXT_DATA(zbb), - RISCV_ISA_EXT_DATA(svpbmt), }; =20 static bool __init is_lowercase_extension_name(const char *str) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 2819ff4e7c..f6f20824e3 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -47,6 +47,8 @@ static struct csr_masks __ro_after_init csr_masks; #define HENVCFG_VALID_MASK 0xe0000003000000ffUL #define HSTATEEN0_VALID_MASK 0xde00000000000007UL =20 +bool __ro_after_init svpbmt_enabled; + void __init init_csr_masks(void) { /* @@ -79,6 +81,10 @@ void __init init_csr_masks(void) INIT_RO_ONE_MASK(HSTATEEN0, hstateen0); } =20 + svpbmt_enabled =3D (riscv_isa_extension_available(NULL, + RISCV_ISA_EXT_svpbmt)) && (ENVCFG_PBMTE & + csr_masks.henvcfg); + #undef INIT_CSR_MASK #undef INIT_RO_ONE_MASK } @@ -97,8 +103,8 @@ static void vcpu_csr_init(struct vcpu *v) */ v->arch.hcounteren =3D HCOUNTEREN_TM; =20 - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) - v->arch.henvcfg =3D ENVCFG_PBMTE & csr_masks.henvcfg; + if ( svpbmt_enabled ) + v->arch.henvcfg =3D ENVCFG_PBMTE; =20 if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) { diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm= /page.h index 1977634efc..a7d087ff52 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -11,6 +11,7 @@ #include =20 #include +#include #include =20 #define VPN_MASK (PAGETABLE_ENTRIES - 1UL) @@ -42,7 +43,21 @@ * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory * 11 - Rsvd Reserved for future standard use + * + * These bits are only meaningful when Svpbmt is enabled. Otherwise they m= ust + * stay 0 (PMA). */ +extern bool svpbmt_enabled; +static inline unsigned long pte_pbmt_nocache(void) +{ + return svpbmt_enabled ? BIT(61, UL) : 0; +} + +static inline unsigned long pte_pbmt_io(void) +{ + return svpbmt_enabled ? BIT(62, UL) : 0; +} + #define PTE_PBMT_NOCACHE BIT(61, UL) #define PTE_PBMT_IO BIT(62, UL) =20 @@ -53,6 +68,7 @@ #define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUT= ABLE | PTE_ACCESSED) =20 #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW + /* * PAGE_HYPERVISOR_NOCACHE is used for ioremap(). * @@ -60,8 +76,8 @@ * is that IO is non-idempotent and strongly ordered, which makes it a good * candidate for mapping IOMEM. */ -#define PAGE_HYPERVISOR_NOCACHE (PAGE_HYPERVISOR_RW | PTE_PBMT_IO) -#define PAGE_HYPERVISOR_WC (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE) +#define PAGE_HYPERVISOR_NOCACHE (PAGE_HYPERVISOR_RW | pte_pbmt_io()) +#define PAGE_HYPERVISOR_WC (PAGE_HYPERVISOR_RW | pte_pbmt_nocache= ()) =20 /* * The PTE format does not contain the following bits within itself; @@ -82,7 +98,7 @@ enum pbmt_type { =20 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE) =20 -#define PTE_PBMT_MASK (PTE_PBMT_NOCACHE | PTE_PBMT_IO) +#define PTE_PBMT_MASK (BIT(61, UL) | BIT(62, UL)) =20 /* Calculate the offsets into the pagetables for a given VA */ #define pt_linear_offset(lvl, va) ((va) >> XEN_PT_LEVEL_SHIFT(lvl)) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 22ad4a2aee..15cbc92b76 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -658,7 +658,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, switch ( t ) { case p2m_mmio_direct_io: - e.pte |=3D PTE_PBMT_IO; + e.pte |=3D pte_pbmt_io(); break; =20 default: --=20 2.55.0 From nobody Thu Sep 24 20:24:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1789032930; cv=none; d=zohomail.com; s=zohoarc; b=dtP2nLkaObfYXO3FbtdGjCRzs/OW3zHf+hAxH718e1qkNbQdWDBeNkJWSWdoJVx73SdoncEnt+BChNN6MQMP5FmTTlzYO4ogLAW7+UMVJ7wkJHuQwci86Qzt/puatDsXhVK9yYDYgTDr46mu+dx2Q+TWGynZSlwQRk6c+xUJ9K8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789032930; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=zCcQNFh0g12JPMddG2Ca8xIh45osQOHtYcniGIWjeXE=; b=F7cjhQvSykOUteqrEwxQptoUhIZFblCmn6H7nultVDCEQhDCVc01bFa9oEzq7wJHLyGm4kiyx5vJVSzDsjQ7mPoM/QGoBxJ8SE9I3UTJmep8+d9PM9DBAWVdEH452KR/z9MEuKmvM98x3dnJ96Oa+ZTVEyFSqBen4gWtrhiM6qs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1789032929707438.08404855823665; Thu, 10 Sep 2026 02:35:29 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1414230.1644027 (Exim 4.92) (envelope-from ) id 1x4bBZ-0003t8-Lk; Thu, 10 Sep 2026 09:35:13 +0000 Received: by outflank-mailman (output) from mailman id 1414230.1644027; Thu, 10 Sep 2026 09:35:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBZ-0003sx-It; Thu, 10 Sep 2026 09:35:13 +0000 Received: by outflank-mailman (input) for mailman id 1414230; Thu, 10 Sep 2026 09:35:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBZ-0003s3-1L for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBY-00G7oY-E1 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279cb-8faa-0a2a0a5109dd-0a2a45038d98-12 for ; Thu, 10 Sep 2026 11:35:12 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279d0-fae8-0a2a45030019-b9ff1c128343-3 for ; Thu, 10 Sep 2026 11:35:12 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aaba10f000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:58 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 3643E81DDF; Thu, 10 Sep 2026 11:34:58 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=zCcQNFh0g12JPMddG2Ca8xIh45osQOHtYcniGIWjeXE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=oUaTveciXV3djdoStuZbp035Tod9lxjUIJV5N/uaryGMr0u0EWDkupTdEyCka8cUCDABlHVxR 6bYEFm0Jc4St/rXDddtPLscXRGQffHfCSFCYQKOhD9gc3Jzhow+r6MbLzu/s8v5hM/p5FRfVj4z cw8JgaWV82/jKblqraJN+HAOVcfwtAsgUDLE89Rjk0XuSEkZ1f5Rk0JnJODTBH3xjxCYP/SGaup 1J4lDAyvVewy8Ke1xHa1aVTGp+hqB4fLzbNgUND/jiy6rHzN0BtVNimYKxVQue2at15ZMf7pX2G 6dO457/neia5ihLW4XUPohpKH1tgDEhMuZ7XexIXa+dQ== X-Zone-Loop: d73f9eca2dae5907b35fb4a46eb39ffdffe62ccb1db2 x-campaign-type: default x-transaction-id: aaae94c8-24f6-4a94-b203-c19ea85e5935 x-swg-uid: 01-4d4eba5c-662a-4f18-af2f-bc0a62b6dd06 X-Mailer: Sweego Message-ID: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> x-swg-bid: 1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension Date: Thu, 10 Sep 2026 11:34:52 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=1274; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=oiDBllyOiotIYkSmw8xo419f4GoaBYdPMeKZi/GUUr4=; b=9p1WqN6dVAil6viKUhFyTXxVDTkqE3OiwnQioTXdPTkSSt3+/xfZwZKRD1xv7ZqSd45Vygn+V 7dEtBVmMbXRB2cYqvxOpB2IydCWjl2NTnkfBqDPOyrIW6qfWnoNn0j/ X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032898419 X-purgate-ID: tlsNG-33051d/1789032912-6FAC44E9-23DC6F3F/0/0 X-purgate-type: clean X-purgate-size: 1276 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1789032930992158500 required_extensions[] panics at boot if Zihintpause is missing, but Xen never actually depends on it: cpu_relax() only emits the "pause" hint when the extension is implemented, otherwise it emits `0x0100000F`, a legally valid FENCE instruction (`FENCE W, 0`) rather than a native NOP. FENCE is guaranteed by the RISC-V base ISA, so it never raises an illegal instruction fault. With an empty successor set, it enforces no memory-ordering constraints and thus architecturally behaves as a NOP. Drop it from required_extensions so hardware without Zihintpause still boots. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - rewrite commit message. --- xen/arch/riscv/cpufeature.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 986a6dec78..41bb1d2e80 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -156,7 +156,6 @@ static const struct riscv_isa_ext_data __initconst requ= ired_extensions[] =3D { RISCV_ISA_EXT_DATA(h), RISCV_ISA_EXT_DATA(zicsr), RISCV_ISA_EXT_DATA(zifencei), - RISCV_ISA_EXT_DATA(zihintpause), RISCV_ISA_EXT_DATA(zbb), }; =20 --=20 2.55.0 From nobody Thu Sep 24 20:24:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1789032929; cv=none; d=zohomail.com; s=zohoarc; b=l7wzc2etUl2PXSSGGz/8KO6GKer46cnTg7Elky6IXBnElyj1hNvuK/irUi5FN6YFyaSF6cS2NgpofAM7dK9i3C0++X3TPi2D+HOTVdetJMoKObQKy58lTyq4864656gx1m8SQTRyZDbpNWNTp+1O/ZQn+0YeJ0/vI3U2h9IMsGg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789032929; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=X/8cvkaIvfN4ORXWCv9sGu6JJ/CUQev1gsouw1gwXDY=; b=IW7LHweJR8p5eLu05lJSeI924kCQTiDGbJglLfE3MYiZmYTDoMLCC2fdJ5HdZi/DrWrltQdJeFaWKvuqBAXgYtPW1mDaQ0qrKiAY26LHfNps1dRtT3zxMBVOcJiG8c6iLedAA02AgQcHIRz9wJQdrT8galwQG74+gSKScTnH9c0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1789032929257903.3680996876728; Thu, 10 Sep 2026 02:35:29 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1414231.1644036 (Exim 4.92) (envelope-from ) id 1x4bBa-00047K-Tz; Thu, 10 Sep 2026 09:35:14 +0000 Received: by outflank-mailman (output) from mailman id 1414231.1644036; Thu, 10 Sep 2026 09:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBa-00047D-Qu; Thu, 10 Sep 2026 09:35:14 +0000 Received: by outflank-mailman (input) for mailman id 1414231; Thu, 10 Sep 2026 09:35:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBa-0003zD-7V for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBZ-004vNh-KY for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279cb-8faa-0a2a0a5109dd-0a2a45038d98-16 for ; Thu, 10 Sep 2026 11:35:13 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279d0-fae8-0a2a45030019-b9ff1c128343-4 for ; Thu, 10 Sep 2026 11:35:13 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aaba238000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:59 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 83BF281E02; Thu, 10 Sep 2026 11:34:58 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=X/8cvkaIvfN4ORXWCv9sGu6JJ/CUQev1gsouw1gwXDY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=d/KG/E5Q+6iDzxx3DY1MpAJVlJrQCl6ys/adIosnB5+2AvYOPRsIbhtMZXkOOfkO5Kn2CB5VW Oe8xpHjg9wx//KDw1j7OLqyse56/wWEOdHC9TwkqxC3bDdH1hvEMXYx0LoMt0QvS9aQC0HmBQYQ 67hIk499KEw0temB4z9eGtgA7Ew42nBgiSJImPuReLdOv+0LR79hFR3zpE/qrZ6oYFtkPJhNoCG BRihAJ8MnT5mPzkGm/vCvL246ETTVglJkjIS2BKIjj+WIbx+o/txvIMf/yhUMOksuSoTm7lKw69 Wg3wca7dXQDcPT78GUmiToWe2JyxNX/C4qxPbZvZqfIA== X-Zone-Loop: 2eb777688ec98a335e6d365e5d176e2b551c73a96b11 x-campaign-type: default x-transaction-id: c0c46c87-1c28-4fce-8319-2dae7e389f67 x-swg-uid: 01-e7b1a648-d90d-48ff-b090-12dd9535cc96 X-Mailer: Sweego Message-ID: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3@vates.tech> x-swg-bid: 1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 5/6] xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu() Date: Thu, 10 Sep 2026 11:34:53 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=1716; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ke7mA7f4Dus9EMjPR0lmZSmqmnKbVtyeE23BIEFxZ5g=; b=t0w307/1fcBfuw+FuOWqjaQqVd0M1voh3gOg4v3raHsmDgjZUSoln+0nnnorn1BTUfZxYn43h D7kGFssZWsXAcI68rvdb2BeoyN35708/HPcXOHZjEy1BiNL4t7DUk3S X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032898729 X-purgate-ID: tlsNG-33051d/1789032913-6DED24E9-A9DFECA2/0/0 X-purgate-type: clean X-purgate-size: 1718 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1789032931000158500 The existing SFENCE.VMA before the satp write only orders the page table stores from setup_initial_pagetables() against subsequent implicit reads. It does not prevent the CPU from speculatively caching translations after the fence retires. According to the RISC-V Privileged specification, implementations are permitted to speculatively cache Bare-mode identity mappings. Furthermore, selecting MODE=3DBare (which happens during check_pgtbl_mode_support()) requires zeroing the remaining fields of satp, causing ASID=3D0 to be actively used in Bare mode. Consequently, the TLB can be polluted with Bare identity mappings tagged with ASID=3D0. Once satp is written to enable Sv39 translation, these cached identity mappings (tagged with ASID=3D0) can shadow the true Sv39 translations. This would lead to translation failures since turn_on_mmu() jumps to a non-identity-mapped linker address. Fix this by adding a post-satp-write SFENCE.VMA to invalidate any stale translations (including Bare-mode identity mappings under ASID=3D0) before jumping to the virtual address space. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Jan Beulich Reviewed-by: Oleksii Kurochko --- Changes since v1: - rewrite commit message --- xen/arch/riscv/riscv64/head.S | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S index 9c40512e61..7f6edc972f 100644 --- a/xen/arch/riscv/riscv64/head.S +++ b/xen/arch/riscv/riscv64/head.S @@ -98,6 +98,7 @@ FUNC(turn_on_mmu) srli t1, t1, PAGE_SHIFT or t1, t1, t0 csrw CSR_SATP, t1 + sfence.vma =20 jr a0 END(turn_on_mmu) --=20 2.55.0 From nobody Thu Sep 24 20:24:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1789032938; cv=none; d=zohomail.com; s=zohoarc; b=ScrXZekUdhmxZgBddqlSSo6RjLPV+yXrszIwNWZZrRxqPUEVptlv9rAaSGPnn8QnDoLeEgrYmehqDKBf46mEtZBoSn4PPmIK2wu/5rSpupdD2jU5IPm9iT+4S1NcAVdDNBKaKfmXILERRi257H+A3uhcNE4YaiLES4LyH2XFBA0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789032938; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=RCwI/CvQHkl5huemyVSULsoFXmRH9tLdrSmGjZIII34=; b=DIVduDUXsizXXwQJGpRNwHi3Wiw/UpagDa8a0vtg2wvJWHwsfgqJYptg18eKguVKxr/HQkObB/Qjazvcpr1A/cUtwb6r8KL2ywjYBIfFLKlYSEARnEYyOEwlaz/zEsvXhIgI3K9WCI9htYBfeTThWLyTfzkaUVrRgCseRa7V+o4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1789032938222480.58686707113145; Thu, 10 Sep 2026 02:35:38 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1414234.1644045 (Exim 4.92) (envelope-from ) id 1x4bBe-0004Px-3z; Thu, 10 Sep 2026 09:35:18 +0000 Received: by outflank-mailman (output) from mailman id 1414234.1644045; Thu, 10 Sep 2026 09:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBe-0004Pq-0y; Thu, 10 Sep 2026 09:35:18 +0000 Received: by outflank-mailman (input) for mailman id 1414234; Thu, 10 Sep 2026 09:35:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBc-0004NG-Rt for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBc-00FAkC-8e for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279d1-2eae-0a2a0a5409dd-0a2a45058730-18 for ; Thu, 10 Sep 2026 11:35:16 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279d3-4cb1-0a2a45050019-b9ff1c228a0d-3 for ; Thu, 10 Sep 2026 11:35:16 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aaba3b8000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:59 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id CE6E281E0F; Thu, 10 Sep 2026 11:34:58 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=RCwI/CvQHkl5huemyVSULsoFXmRH9tLdrSmGjZIII34=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=CJ4qTI7zUwSds4AzJvDmNfX7YW154myeoHUFQe2iaBY7fW/xrNaZmBACelc4yNhvogY61uwIJ 8+l5baFBzH6O2K0Lcs6pR7EYUQNff6p/UTRv/JyBA+VVvyVnHKlbPPQ6yS/zwGqiyr9aNbpPLHw b+sM0RVkyEITuT+HyJEZj36z1fq3OKtHYWGIAx0W+nZeJAurP8tZkd5bVvZSE6VA9lJIhVr5Ied Wdws9cTUHRTbnTHDkLDysMLGeTRNhuTEkChqXKNE2JOBaLIUdqlVwOEMrAUpvP8GpC7y72kohNI 5H6Z2Q1uhn2YwpnGN8p4uZFVOA7Levr2tLHwv1L51JxA== X-Zone-Loop: 18e32e81ebd0207eee728b0687c3892bf11de8fca549 x-campaign-type: default x-transaction-id: d4089c17-9daa-4106-9d65-11b371a56fce x-swg-uid: 01-5b7aa16d-d323-4cb3-9789-779f9dbd7309 X-Mailer: Sweego Message-ID: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> x-swg-bid: 1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Zheng Zhang Subject: [PATCH v2 6/6] xen/riscv: fix level_map_mask truncation on load_start Date: Thu, 10 Sep 2026 11:34:54 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=2391; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=EukpbiTX/G19DWwnVmYEkUdIYk1+eY5cBq7NCGMGSwY=; b=5NN6pbNqsPZBOVYzXv7RM+d3wJTOBMlrqhqWaPZw16orp1hq1gxMAcUo/9v3z16gOZQIG9Mxg 4OVRQ8S/7ZlC0jdgROlf36Q0X62pXqyCXUk+qUwtjSkZZEnt+9AVnJ4 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032899042 X-purgate-ID: tlsNG-c201ff/1789032916-F6EB12A1-6F3DD476/0/0 X-purgate-type: clean X-purgate-size: 2393 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1789032938754158500 check_pgtbl_mode_support() declares level_map_mask as bare `unsigned`, i.e. a 32-bit type while it derives from a paddr_t which is in both RV32/RV64 a 64-bit type. Storing that value into a 32-bit local silently drops any set bits above bit 31. The mask is then used as: aligned_load_start =3D load_start & level_map_mask; load_start is `unsigned long` (64-bit on riscv64) and if it requires more than 32 bits to represent, because load_start zero-extend to 64 bits, we would drop some load_start's bits during the AND. Widen level_map_mask to `unsigned long`, matching the width of the physical address. Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Reported-by: Zheng Zhang Signed-off-by: Baptiste Le Duc Reviewed-by: Jan Beulich Tested-by: Zheng Zhang --- Changes since v1: - new patch --- Question: I would think replacing unsigned long by paddr_t would be better in this case but for consistency with other variables in the function I just kept unsigned long. However, there are many variables in mm.c which are unsigned long while they are, in reality, physical addresses and could technically be paddr_t. Using paddr_t would also let us bypass the compiler's decision on what unsigned long extends to (u32 or u64, depending on the target), and therefore be more generic. I've seen similar code in Arm using this convention, and found nothing on the mailing list explaining the original choice of unsigned long over paddr_t. Replacing every such field would be a fairly large change, so I'm asking for your opinion on whether it's worth doing. --- xen/arch/riscv/mm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 53bebbcabf..e7f2491257 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -180,7 +180,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_= desc *mmu_desc, bool is_mode_supported =3D false; unsigned int index; unsigned int page_table_level =3D (mmu_desc->num_levels - 1); - unsigned level_map_mask =3D XEN_PT_LEVEL_MAP_MASK(page_table_level); + unsigned long level_map_mask =3D XEN_PT_LEVEL_MAP_MASK(page_table_leve= l); =20 unsigned long aligned_load_start =3D load_start & level_map_mask; unsigned long aligned_page_size =3D XEN_PT_LEVEL_SIZE(page_table_level= ); --=20 2.55.0