[milspec]

MMU?

I see one place seemingly using RISC-V with an MMU in the classic desktop PowerPC style (Linus Torvalds posted a great rant about the stupidity of that MMU) and another place that is seemingly using RISC-V with an MMU that is very much like x86 (the paging part, obviously no segmentation) but with distinct rwx.

Which is it? Did this not get specified? Constantly changing the MMU greatly hurt 32-bit SPARC and PowerPC.

FWIW, this is good: Bits 0..11 direct mapped, bits 12..29 are x86-style page table tree node indexes that are hardware-walked, and bits 30..63 are software-filled like MIPS. (a forest of trees) In the low bits of the bottom level you get: can read, did read, can write, did write, can execute, did execute, user/super (exclusive), type ram/framebuffer/mmio/pte (two bits), reserved, and validity. The "did foo" bits on PTE pages do get updated.

[_chris_]

You can find your answers in the Privileged ISA spec (http://riscv.org/download.html#tab_spec_privileged_isa).

Of course, it's an open ISA, so you can do whatever you want. The style of virtual memory you choose to use will depend on the target application.

[milspec]

Thanks. The following concerns paging, not the base/limit system:

From a security and reliability perspective, I'm saddened to see that rwx got supported while --x did not get supported. That is backwards. Having to change permissions after code modification is not bad; this provides a convenient point for cache flushing and ASLR-enforced address changes. Preventing executable code from being misused as data is valuable.

I'm also saddened to see that user access implies supervisor access. This too is exactly backwards; nothing should be both user and supervisor accessible. Given that data access can be performed at a less-privileged level by setting MPRV=1, the ability of the supervisor to access user pages normally is especially strange.

Lack of distinct did-execute and did-read bits is mildly annoying. If a page is marked as being accessed and executable, one must assume that it is now in BOTH the instruction cache and the data cache.

I have mixed feelings about having page frame numbers shifted over by two bits. The win is Sv32 getting a reach of 16 GiB. I suppose this is worth the minor annoyance when debugging OS kernel code.

Other than that, I like it. It's certainly sane. The traditional page table is pretty good for the middle bits of the virtual address. I think it is less good for the upper bits due to ASLR, and I hate to see anything that encourages a failure to use all 64 bits of the virtual address space.

[_chris_]

You should read through the RISCV mailing list archives (https://lists.riscv.org/lists/) for discussions on these topics, and contribute your own thoughts if they haven't been covered. The ISA-dev list should be the most relevant. They have thought very carefully about these things and I'm sure they'd appreciate additional feedback on the topic.

[milspec]

Oh, one other problem. The referenced (R) and dirty (D) bits are only updated in leaf nodes. I strongly suspect that any performance you gain here will be more than consumed by OS software needing to scan all the leaf nodes for these bits. If you update non-leaf nodes, then the OS can use those to avoid checking many of the leaf nodes.