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

[Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>]

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: Always preset A/D bits in G-stage PTEs
    2: Fix A/D bit handling in Xen's page-table mappings
    3: Use pte_is_valid() in pte_is_mapping()

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

---
Changes since v4:
- Drop patches merged upstream:
    ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"")
- Collect trailers.
- Rebase patches on top of staging.
- Link to v4: 
https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@xxxxxxxxxx
---
Changes since v3:
- Drop v3 patches 1, 6 already upstreamed:
    861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required
    extension")
    469d83d42f5c ("docs/riscv: sync required ISA extensions with
    required_extensions[]")
- Add trailers (A-by and/or R-by).
- Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs")
  as it now always presets A/D bits instead of distinguish Svadu/Svade DT
  bindings cases.
- Address review comments.
- Link to v3: 
https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@xxxxxxxxxx
---
Changes since v2:
- Drop v2 patches 5 and 6, already upstreamed:
    d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries 
in turn_on_mmu()")
    08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start")
- Drop "xen/riscv: make Svpbmt no longer a required extension".
  It relaxed Svpbmt so boards without it, like the HiFive P550, could boot.
  But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches
  and can read stale data from DRAM. Mainline Linux has the same problem,
  which is explained and reproducible in [1]. Fixing it needs a lot of
  machinery we do not need yet, and Svpbmt is mandatory in RVA23, so
  keeping it required is simpler and safer. An RFC will follow with a fix
  inspired by [2].
- Add three new patches:
    docs/riscv: sync required ISA extensions with required_extensions[]
    xen/riscv: rename PTE "permissions" to "pte_flags"
    xen/riscv: use pte_is_valid() in pte_is_mapping()
- Address review comments.

[1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master
[2] https://lwn.net/Articles/996819/
---
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: xen-devel@xxxxxxxxxxxxxxxxxxxx
Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Cc: Michal Orzel <michal.orzel@xxxxxxx>
Cc: Jan Beulich <jbeulich@xxxxxxxx>
Cc: Julien Grall <julien@xxxxxxx>
Cc: Roger Pau Monné <roger@xxxxxxxxxxxxxx>
Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Cc: Alistair Francis <alistair.francis@xxxxxxx>
Cc: Connor Davis <connojdavis@xxxxxxxxx>
Cc: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
Cc: Zheng Zhang <zhangzheng@xxxxxxxxxxx>

---
Baptiste Le Duc (3):
      xen/riscv: always preset A/D bits in G-stage PTEs
      xen/riscv: fix A/D bits in Xen's page-table mappings
      xen/riscv: use pte_is_valid() in pte_is_mapping()

 xen/arch/riscv/include/asm/page.h | 35 ++++++++++++++++++-----------------
 xen/arch/riscv/mm.c               | 11 +++++------
 xen/arch/riscv/p2m.c              | 38 ++++++++------------------------------
 3 files changed, 31 insertions(+), 53 deletions(-)
---
base-commit: e4da1829737fb575133d1f79d9ad987000891649
change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694

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