[PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs

[PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs

[Baptiste Le Duc]

This series introduces bugs fixes that were found while bringing up CI
support for the HiFive Premier P550 board with a basic smoke test. The
board-support series itself will follow separately as it depends on
PLIC/vPLIC and dom0less support that have not been upstreamed yet. This
series carries only the independent fixes found along the way, none of them
need the board-support series to apply.

This series:
    1: Fix Svade/Svadu A/D bit handling
    2: Set A/D bits in Xen's own page-table mappings under Svade
    3: Make Svpbmt no longer a required extension
    4: Make Zihintpause no longer a required extension
    5: Flush speculatively cached Bare-mode TLB entries in turn_on_mmu()
    6: Fix level_map_mask truncation on load_start

CI pipeline:
https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2836284276

---
Changes since v1:
- address ML comments
- rename some patchs
- add new patch-fix: 242dd1f890e4 ("xen/riscv: fix level_map_mask
  truncation on load_start") discovered when working on Spacemit K3 support

To: Zheng Zhang <Zheng Zhang <zhangzheng@iscas.ac.cn>
To: Alistair Francis <alistair.francis@wdc.com>
To: Connor Davis <connojdavis@gmail.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
To: Anthony PERARD <anthony.perard@vates.tech>
To: Michal Orzel <michal.orzel@amd.com>
To: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
To: Roger Pau Monné <roger@xenproject.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org

---
Baptiste Le Duc (6):
      xen/riscv: fix Svade/Svadu A/D bit handling
      xen/riscv: set A/D bits in Xen's page-table mappings under Svade
      xen/riscv: make Svpbmt no longer a required extension
      xen/riscv: make Zihintpause no longer a required extension
      xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()
      xen/riscv: fix level_map_mask truncation on load_start

 xen/arch/riscv/cpufeature.c             | 61 +++++++++++++++++++++++++++++++--
 xen/arch/riscv/domain.c                 | 10 ++++--
 xen/arch/riscv/include/asm/cpufeature.h |  1 +
 xen/arch/riscv/include/asm/page.h       | 37 ++++++++++++++------
 xen/arch/riscv/include/asm/sbi.h        |  8 +++++
 xen/arch/riscv/mm.c                     | 11 +++---
 xen/arch/riscv/p2m.c                    | 49 ++++++++++----------------
 xen/arch/riscv/riscv64/head.S           |  1 +
 8 files changed, 127 insertions(+), 51 deletions(-)
---
base-commit: f7eab298bb9f2634e555aea1db70efcbbfd4d316
change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694

Best regards,
--  
Baptiste Le Duc <baptiste.le-duc@vates.tech>

[PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling

[Baptiste Le Duc]

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 PBMT configuration")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
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 @@
 
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
+#include <asm/sbi.h>
 
 #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;
 }
 
+/*
+ * 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 indicates
+ * that a page fault will be raised. In contrast, the Svadu extension supports
+ * hardware updating of the PTE A/D bits.
+ *
+ * There are 4 possible combinations of these extensions in the device tree.
+ * The default hardware behavior for each is:
+ *
+ * 1) Neither Svade nor Svadu present in DT => 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 when
+ *    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 => Xen must assume Svade to be always enabled.
+ *
+ * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled.
+ *
+ * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned 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 won'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 = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade);
+    bool svadu = 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, but 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);
     }
 
+    riscv_resolve_ad_scheme();
+
     for ( i = 0; i < req_extns_amount; i++ )
     {
         const struct riscv_isa_ext_data ext = required_extensions[i];
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/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
 };
 
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
 
 /* 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);
 
+/**
+ * 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)
 
 static void p2m_set_permission(pte_t *e, p2m_type_t t)
 {
+    bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade);
+    bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu);
+
     e->pte &= ~PTE_ACCESS_MASK;
 
     e->pte |= PTE_USER;
 
     /*
-     * Two schemes to manage the A and D bits are defined:
-     *   • The Svade extension: when a virtual page is accessed and the A bit
-     *     is clear, or is written and the D bit is clear, a page-fault
-     *     exception is raised.
-     *   • When the Svade extension is not implemented, the following 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-stage
-     *     address translation is in use and is not Bare, the G-stage virtual
-     *     pages may be accessed or written by implicit accesses to VS-level
-     *     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’s 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/Svadu
+     * 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 mentioned
-     *       above, it would be better to stop setting the A/D bits here and
-     *       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 != svadu); /* exactly one of svade/svadu must be set by riscv_fill_hwcap() */
+    if ( svade )
         e->pte |= PTE_ACCESSED | PTE_DIRTY;
 
     switch ( t )

-- 
2.55.0

[PATCH v2 2/6] xen/riscv: set A/D bits in Xen's page-table mappings under Svade

[Baptiste Le Duc]

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 <baptiste.le-duc@vates.tech>
---
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)
 
-#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
 #define PTE_TABLE                   (PTE_VALID)
 
-#define PAGE_HYPERVISOR_RO          (PTE_VALID | PTE_READABLE)
-#define PAGE_HYPERVISOR_RW          (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
-#define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
+#define PAGE_HYPERVISOR_RO          (PTE_VALID | PTE_READABLE | PTE_ACCESSED)
+#define PAGE_HYPERVISOR_RW          (PTE_VALID | PTE_READABLE | PTE_WRITABLE | PTE_ACCESSED | PTE_DIRTY)
+#define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE | PTE_ACCESSED)
 
 #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=1 and W=1 then R also needs to be 1 as
      * R = 0 is reserved for future use ( look at the Table 4.5 ) so check
      * in ASSERT that if (V==1 && W==1) then R isn't 0.
-     *
-     * PAGE_HYPERVISOR_RW contains PTE_VALID too.
      */
-    ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE)));
+    ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=
+           (PTE_VALID | PTE_WRITABLE));
 
     return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == 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) != (PTE_VALID | PTE_WRITABLE)));
+    ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=
+            (PTE_VALID | PTE_WRITABLE));
 
     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_desc *mmu_desc,
         case 1: /* Level 0 */
             {
                 unsigned long paddr = (page_addr - map_start) + pa_start;
-                unsigned int permissions = PTE_LEAF_DEFAULT;
+                unsigned int permissions = PAGE_HYPERVISOR_RW;
                 unsigned long addr = 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_desc *mmu_desc,
 
                 if ( is_kernel_text(addr) ||
                      is_kernel_inittext(addr) )
-                        permissions =
-                            PTE_EXECUTABLE | PTE_READABLE | PTE_VALID;
+                    permissions = PAGE_HYPERVISOR_RX;
 
                 if ( is_kernel_rodata(addr) )
-                    permissions = PTE_READABLE | PTE_VALID;
+                    permissions = PAGE_HYPERVISOR_RO;
 
                 pte_to_be_written = paddr_to_pte(paddr, permissions);
 
@@ -198,7 +197,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc *mmu_desc,
 
     index = pt_index(page_table_level, aligned_load_start);
     stage1_pgtbl_root[index] = paddr_to_pte(aligned_load_start,
-                                            PTE_LEAF_DEFAULT | PTE_EXECUTABLE);
+                                            PAGE_HYPERVISOR_RX);
 
     sfence_vma();
     csr_write(CSR_SATP,

-- 
2.55.0

[PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension

[Baptiste Le Duc]

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 <baptiste.le-duc@vates.tech>

---
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 required_extensions[] = {
     RISCV_ISA_EXT_DATA(zifencei),
     RISCV_ISA_EXT_DATA(zihintpause),
     RISCV_ISA_EXT_DATA(zbb),
-    RISCV_ISA_EXT_DATA(svpbmt),
 };
 
 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
 
+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);
     }
 
+    svpbmt_enabled = (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 = HCOUNTEREN_TM;
 
-    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) )
-        v->arch.henvcfg = ENVCFG_PBMTE & csr_masks.henvcfg;
+    if ( svpbmt_enabled )
+        v->arch.henvcfg = ENVCFG_PBMTE;
 
     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 <xen/types.h>
 
 #include <asm/atomic.h>
+#include <asm/cpufeature.h>
 #include <asm/page-bits.h>
 
 #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 must
+ * 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)
 
@@ -53,6 +68,7 @@
 #define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE | PTE_ACCESSED)
 
 #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())
 
 /*
  * The PTE format does not contain the following bits within itself;
@@ -82,7 +98,7 @@ enum pbmt_type {
 
 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
 
-#define PTE_PBMT_MASK   (PTE_PBMT_NOCACHE | PTE_PBMT_IO)
+#define PTE_PBMT_MASK   (BIT(61, UL) | BIT(62, UL))
 
 /* 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 |= PTE_PBMT_IO;
+            e.pte |= pte_pbmt_io();
             break;
 
         default:

-- 
2.55.0

[PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension

[Baptiste Le Duc]

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 <baptiste.le-duc@vates.tech>
---
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 required_extensions[] = {
     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),
 };
 

-- 
2.55.0

[PATCH v2 5/6] xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()

[Baptiste Le Duc]

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=Bare (which happens during check_pgtbl_mode_support())
requires zeroing the remaining fields of satp, causing ASID=0 to be
actively used in Bare mode. Consequently, the TLB can be polluted with Bare
identity mappings tagged with ASID=0.

Once satp is written to enable Sv39 translation, these cached identity
mappings (tagged with ASID=0) 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=0) before
jumping to the virtual address space.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
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
 
         jr      a0
 END(turn_on_mmu)

-- 
2.55.0

[PATCH v2 6/6] xen/riscv: fix level_map_mask truncation on load_start

[Baptiste Le Duc]

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 = 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 <zhangzheng@iscas.ac.cn>
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
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 = false;
     unsigned int index;
     unsigned int page_table_level = (mmu_desc->num_levels - 1);
-    unsigned level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level);
+    unsigned long level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level);
 
     unsigned long aligned_load_start = load_start & level_map_mask;
     unsigned long aligned_page_size = XEN_PT_LEVEL_SIZE(page_table_level);

-- 
2.55.0

Re: [PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs

[Jan Beulich]

On 10.09.2026 11:30, Baptiste Le Duc wrote:
> This series introduces bugs fixes that were found while bringing up CI
> support for the HiFive Premier P550 board with a basic smoke test. The
> board-support series itself will follow separately as it depends on
> PLIC/vPLIC and dom0less support that have not been upstreamed yet. This
> series carries only the independent fixes found along the way, none of them
> need the board-support series to apply.
> 
> This series:
>     1: Fix Svade/Svadu A/D bit handling
>     2: Set A/D bits in Xen's own page-table mappings under Svade
>     3: Make Svpbmt no longer a required extension
>     4: Make Zihintpause no longer a required extension
>     5: Flush speculatively cached Bare-mode TLB entries in turn_on_mmu()
>     6: Fix level_map_mask truncation on load_start
> 
> CI pipeline:
> https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2836284276
> 
> ---
> Changes since v1:
> - address ML comments
> - rename some patchs
> - add new patch-fix: 242dd1f890e4 ("xen/riscv: fix level_map_mask
>   truncation on load_start") discovered when working on Spacemit K3 support
> 
> To: Zheng Zhang <Zheng Zhang <zhangzheng@iscas.ac.cn>
> To: Alistair Francis <alistair.francis@wdc.com>
> To: Connor Davis <connojdavis@gmail.com>
> To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> To: Andrew Cooper <andrew.cooper3@citrix.com>
> To: Anthony PERARD <anthony.perard@vates.tech>
> To: Michal Orzel <michal.orzel@amd.com>
> To: Jan Beulich <jbeulich@suse.com>
> To: Julien Grall <julien@xen.org>
> To: Roger Pau Monné <roger@xenproject.org>
> To: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org

Please can you adhere to patch submission rules? Patches are to be sent To:
the list, with relevant people Cc:-ed.

Jan

Re: [PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs

[Baptiste Le Duc]

On 2026-09-10 11:47 +0200, Jan Beulich wrote:
> On 10.09.2026 11:30, Baptiste Le Duc wrote:
> > This series introduces bugs fixes that were found while bringing up CI
> > support for the HiFive Premier P550 board with a basic smoke test. The
> > board-support series itself will follow separately as it depends on
> > PLIC/vPLIC and dom0less support that have not been upstreamed yet. This
> > series carries only the independent fixes found along the way, none of them
> > need the board-support series to apply.
> > 
> > This series:
> >     1: Fix Svade/Svadu A/D bit handling
> >     2: Set A/D bits in Xen's own page-table mappings under Svade
> >     3: Make Svpbmt no longer a required extension
> >     4: Make Zihintpause no longer a required extension
> >     5: Flush speculatively cached Bare-mode TLB entries in turn_on_mmu()
> >     6: Fix level_map_mask truncation on load_start
> > 
> > CI pipeline:
> > https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2836284276
> > 
> > ---
> > Changes since v1:
> > - address ML comments
> > - rename some patchs
> > - add new patch-fix: 242dd1f890e4 ("xen/riscv: fix level_map_mask
> >   truncation on load_start") discovered when working on Spacemit K3 support
> > 
> > To: Zheng Zhang <Zheng Zhang <zhangzheng@iscas.ac.cn>
> > To: Alistair Francis <alistair.francis@wdc.com>
> > To: Connor Davis <connojdavis@gmail.com>
> > To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > To: Andrew Cooper <andrew.cooper3@citrix.com>
> > To: Anthony PERARD <anthony.perard@vates.tech>
> > To: Michal Orzel <michal.orzel@amd.com>
> > To: Jan Beulich <jbeulich@suse.com>
> > To: Julien Grall <julien@xen.org>
> > To: Roger Pau Monné <roger@xenproject.org>
> > To: Stefano Stabellini <sstabellini@kernel.org>
> > Cc: xen-devel@lists.xenproject.org
> 
> Please can you adhere to patch submission rules? Patches are to be sent To:
> the list, with relevant people Cc:-ed.
> 
Sorry, first time I used b4 tool which automatically added the To: and I
missed that during the dry-run... I'd like to do a .b4-config with the
submission rules that could be added in the repo, do you think it could
be a good idea?
> Jan
> 
> 
>