debug: Sv39 identity mappings incompatible with platforms that have main memory at addresses bigger than 38 bits

[alikates]

Hello,
I'm trying to run the Sv39 debug test on a platform that has 40 bit physical addresses. The start of main memory is placed at 0x80_0000_0000. This prevents the test from working because the core detects an incorrectly sign-extended address (bit 39 is 1, but 38 isn't) and triggers a page fault on the first memory access after enabling virtualization and configuring mprv.

Right now I don't really know how to solve this, but I guess supporting these scenarios would require to stop relying on the identity mapping for checking the correct reads and writes from debug mode.

[aap-sc]

Right now I don't really know how to solve this, but I guess supporting these scenarios would require to stop relying on the identity mapping for checking the correct reads and writes from debug mode.

1. I would just mark this test as unsupported on your platform. This can be done by introducing a new method, so we could check the properties of underlying physical addressed.

2. As for stopping using identity mapping - the desired mapping should be a property of the target then..

3. In opinion supporting of c tests where VA != PA is an overkill. Alternative would be to generate have a (relatively) simple assembly program with page table would be dynamically rendered - based on the desired virtual to physical mapping provided by the target). The only problem major is that I don't believe we have such a script out-of-the box. Then if we have pte - the reset like setting satp and the desired mode for translation can be done by OpenOCD commands. @alikates does this approach looks reasonable to you?

[alikates]

Marking it as unsupported is not an option for me, as I want to ensure that this functionality works. I will try to write that script that you say. So we are in the same page, you mean writing the page table from OpenOCD and then generate a simple program that performs the reads and writes?

[aap-sc]

So we are in the same page, you mean writing the page table from OpenOCD and then generate a simple program that performs the reads and writes?

I would even simply further. We can generate page table with python and just embed it into assembly file. Then set satp/modes via OpenOCD (or the program itself).

[aap-sc]

Marking it as unsupported is not an option for me, as I want to ensure that this functionality works.

Here I meant that this specific test is not suitable for your target and we have no way to express this in this testing framework currently. This is a proposal to extend the framework so we can automatically detect that the test should not run for such configurations. While that test is disabled, there is a viable alternative with generation of page tables by an external script.

[aap-sc]

To be more concrete, here is an example.

WARNING: I decided to vibe-code like there is no tomorrow and used deepseek to produce generator of page tables. Likely this generator is borderline non-functional for more complex cases, but it is decent enough for the basic example.

The generator: https://github.com/aap-sc/riscv-tests/blob/aap-sc/vibe_coding_demo1/debug/vibe_code_mmu/mmu_gen2.py

If you run it, you'll get the following output:

> python3 mmu_gen2.py
...

--ASM STARTS HERE---
.global page_table
.global _entry
.text
page_table:

  .fill 2048
  .8byte 0x2000000401
  .fill 2040
  .8byte 0x2000000801
  .fill 4088
  .8byte 0x2000004007
  .fill 4088

.balign 8
_entry:
  j _entry

--LINKER SCRIPT HERE---
ENTRY ( _entry ) SECTIONS { .text 0x8000000000:  { *(.text) } }

Copy the resulting assembly to asm.S and the linker script to asm.ld . Now, if you compile/link that, like this:

riscv64-unknown-elf-gcc -nostartfiles asm.S -T asm.ld -o img.elf

Run spike:

spike --rbb-port=1111 -p1 --isa=rv64gcv_zicntr --dm-progsize=6 -m0x8000000000:0x100000 img.elf

Connect with OpenOCD:

openocd -c "remote_bitbang port 1111" ...

In telnet:

> reset halt
JTAG tap: tap.0 tap/device found: 0xdeadbeef (mfg: 0x777 (Fabric of Truth Inc), part: 0xeadb, ver: 0xd)
> load_image vibe_code_mmu/img.elf
12290 bytes written at address 0x8000000000
downloaded 12290 bytes in 0.097655s (122.902 KiB/s)

> # this performs write to physical address
> mwd 0x8000010000 666

> set mode 8
8

> set addr 0x8000000000
0x8000000000

> # set translation mode
> reg satp [format 0x%x [expr { ($mode << 60) | ($addr >> 12) }]]
satp (/64): 0x8000000008000000

> # supervisor mode (it still displays 3 because of a known bug in OpenOCD, but you can read priv again to ensure that it was set)
> reg priv 1
priv (/8): 0x03


> # now since translation and privileged is set up OpenOCD will perform access using virtual address
> mdd 0xffffffc000000000
0xffffffc000000000: 000000000000029a

Most likely you'll need to tinker with this procedure to perform platform-specific initialization, etc. However, the example is quite illustrative, I believe - once you have a decent mmu generator, I think it should not be hard to integrate it in this repository.

[aswaterman]

This wouldn't be acceptable upstream, of course.

My own take is that upstream tests don't need to support implementations that can't handle identity mappings. That questionable decision should be the vendor's responsibility to deal with.

[aap-sc]

This wouldn't be acceptable upstream, of course.

@aswaterman could you elaborate on this? I mean let's suppose that we have some kind of generator capable to generate page tables. It seems to me that is not that big of a deal to adjust debug tests infrastructure to be able to load such table using either OpenOCD commands directly (via monior command) or by some other way (like embedding it inside the elf). What's wrong with such approach?

[aswaterman]

I meant that the approach looks a little brittle and hacked together. A robust version of this that's also backwards compatible would be fine.