On 5/27/2026 5:13 PM, Philippe Mathieu-Daudé wrote:
PTE_N and PTE_PBMT are undefined on RV64, assert we are not
under RV32.


I didn't find this info in the RV priv ISA.  Can you please quote the
except it in the commit msg?

Maybe you meant "undefined on RV32"?


Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
---
  target/riscv/cpu_helper.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 17305e1bb75..f86bfdb32e7 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1490,6 +1490,7 @@ static int get_physical_address(CPURISCVState *env, 
hwaddr *physical,
          return TRANSLATE_FAIL;
      }
      if (!pbmte && (pte & PTE_PBMT)) {
+        assert(riscv_cpu_sxl(env) != MXL_RV32);


What I understood from the RV priv ISA w.r.t PTE_PMBT is that it doesn't
have much to do with SXLEN/riscv_cpu_sxl().  PTE_PBMT is a bits 62|61 field
that determine override mem attributes when we have the 'svpbmt' extension
enabled.  'svpbmt' is dependent on satp_mode sv39 or greater, which happens
to be riscv64 only.

I didn't see any restrictions of SXLEN=32 in the 'svpbmt' chapter in the
RISC-V ISA, e.g. PTE_PMBT set to a non-zero val and SXLEN=32 seems to be
a valid combo - a riscv64 target running sv39+ can use svpbmt to override
PTE properties in a SXLEN=32 context.

Now, PTE_PBMT is not writable when MXLEN=32 (i.e. riscv_cpu_mxl() == MXL_RV32),
and maybe this is what you're trying to do.  In this case the assert might
be justifiable, although we just landed a recent fix in Alistair's tree
that disables svpbmt for riscv32 entirely, and this also means that
PTE_PBMT won't ever be set.  But if the assert (with MXL, not SXL) would give
some sort of guarantee aside from the bit being set, by all means go ahead.


          /* Reserved without Svpbmt. */
          qemu_log_mask(LOG_GUEST_ERROR, "%s: PBMT bits set in PTE, "
                        "and Svpbmt extension is disabled: "
@@ -1643,6 +1644,7 @@ static int get_physical_address(CPURISCVState *env, 
hwaddr *physical,
      target_ulong vpn = addr >> PGSHIFT;
if (riscv_cpu_cfg(env)->ext_svnapot && (pte & PTE_N)) {
+        assert(riscv_cpu_sxl(env) != MXL_RV32);


All the stuff I said above happens to be applicable for PTE_N.  This is a bit
that indicates if the PTE represents a "naturally aligned power-of-2" range,
or NAPOT range, and this is specified by another extension called 'svnapot'.
This extension is also sv39+ exclusive, which means riscv64 exclusive, and it
doesn't seem to have any restrictions with SXLEN=32.


Thanks,
Daniel

          napot_bits = ctzl(ppn) + 1;
          if ((i != (levels - 1)) || (napot_bits != 4)) {
              return TRANSLATE_FAIL;


Reply via email to