Sv39

[redhog]

Hi! I'm trying to get sv39 / riscv64 mmu to work. I think I have most of of it set up, but it doesn't work somehow. The only test I have is a linux kernel with mmu enabled, which is a pretty bad test. How did you test the sv32 implementation?

Here's my debug output:

priv=3, mode=8: 800000a4
=> machine mode
priv=3, mode=8: 800000a8
=> machine mode
priv=3, mode=8: ffffffff80001084
=> machine mode
Invalid Address, or no valid write pointer found, write not executed!: Addr: ffffffff80001084 Len: 8 Cycle: 62130  PC: ffffffff80001084

So, somehow, the kernel is in machine mode (3) but sets the satp mode to 8 (sv39), then tries to access an address that is definitely not a physical address. Why? How is this supposed to work? I would assumed that priv = 0 before it attempted something like that?

Thanks in advance,
Egil

P.s. this PR includes my other pr (that works) for a pmem based ramdisk, diff with that branch to get the actual diff of only my sv39 implementation.

[franzflasch]

Sv39 would be a great addition! It's been a long time since I dealt with this. So I need some time to look into it again. tbh I did not do a lot of high sophisticated testing. However there are some code examples that I wrote: https://github.com/franzflasch/riscv-test-scripts/tree/main/mmu

I used those to test some basic functionality of the mmu. The idea is to run this on qemu and then compare the behavior with riscv_em.

[redhog]

Will have a look at the tests there, that seems promising.
I guess my main problem is not knowing enough of the Linux kernel boot sequence to figure out what its trying to do when it fails...

[redhog]

I have to admit I'm a bit stuck... Any help in figuring out what goes wrong would be appreciated. From what I have been able to google, priv=3 combined with satp.mode=8 (or any other value than 0) shouldn't really ever happen, as in, it's undefined behavior. Still, the linux kernel does it! Why?