Something RIchard Miller said has got stuck in my head. I am wondering about memory layout on riscv64.
The old tradition of "kernel at bottom of physical, top of virtual" is something we've always done. But do we have to? There are good riscv reasons to flip this. M mode, for example, has no virtual addressing, and it would be useful (to say the least) to have kernel and M mode have a common set of addresses. Further, the PMP registers, which can be used to manage/limit physical memory accesses, only gate addresses: they don't come with an offset. If we had kernel addresses that were 0-based and identity mapped, then the addresses would be the same for kernel, M mode, PMP, and IOMMU. A convenience of the "kernel in high memory" was the fact that an immediate 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such that you can address a KVA with a 32-bit immediate, and a UVA with a 32-bit immediate, as long as it is < 0x80000000. But this comes with a headache: KVA breaks into a 2G region and "the rest", so you end up with two kernel VA ranges. It's annoying at least. The sign extend hack was convenient when 2G was a lot of memory, but after that, it's a bit of a pain. Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one instruction, so having a big number for a base virtual address is not the issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with a 64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to 64 bits). So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user addresses are 1<<62 to (1<<62)-1. This means valid addresses are always int64, but will never be negative; we can keep using u64int. 62 bits of address space ought to be enough for everybody. Again, this makes a lot of RISC-V things easier. It would make it much easier to use kernel addresses for M mode code, because no translation would be needed, and a bunch of other risc-v mechanisms would be similarly simplified. I'm not sure the toolchain can handle having user text start at 0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in 2014, Russ added the code to 6l to allow us to link text in very high memory. So it has to be doable. The code's there in go1.4 :-) Comments? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M67136852f364f333004b7db0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
