Re: [PATCH v11 03/12] target/riscv: Assert PTE.N/PBMT bits are not expected on RV32

[Philippe Mathieu-Daudé]

On 28/5/26 22:01, Daniel Henrique Barboza wrote:

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"?

Yes :)

Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
---
  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.

It was hard to figure that out by myself.

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.

Yes.

  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.

I'll wait to see that merged before revisiting. This patch is not
required for this series, I was trying to make sense of this huge
function while reviewing it.

          /* 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.

OK. Let's discard this patch :)

Thanks,
Daniel

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