- [RISC-V] [tech-virt-mem] Help needed on physical address issues
Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues
To whom it may concern,
Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified:
1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?
2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?
3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?
The way to view this matter is that PA's are full 56-bit zero-extended values. It is up to PMAs to, for example, mark the top six bits of PA space as a big 'vacant' region that results in an Access Fault on all attempted accesses with PA[55:50] != 'b000000. That 'vacant' PMA region can of course be a "fixed" PMA region that only requires the address decode logic gates to implement.
The new (in development) RISC-V Unified Discovery mechanism will support low-level discovery of exactly things like this (and many other things). If you're running, for example, a Linux OS, then higher-level (post OS boot) discovery would typically be provided via Device Tree of ACPI tables.
Join email@example.com to automatically receive all group messages.