On Mon, 8 Jun 2026 at 13:16, Daniel Henrique Barboza <[email protected]> wrote: > On 6/8/2026 7:08 AM, Peter Maydell wrote: > > On Mon, 8 Jun 2026 at 10:47, Daniel Henrique Barboza > > <[email protected]> wrote: > > Do you have a reference in the architecture spec for the check that > > you're trying to implement here ? > > Sure. It's on the RISC-V Privileged ISA, chapter 12, section > 12.3.2 "Virtual Address Translation Process": > > https://docs.riscv.org/reference/isa/_attachments/riscv-privileged.pdf > > 9. If pte.a=0, or if the original memory access is a store and pte.d=0: > - If the Svade extension is implemented, stop and raise a page-fault > exception corresponding to the original access type > - If a store to the PTE at address a+va.vpn[i]×PTESIZE would violate a > PMA or PMP check, raise an access-fault exception corresponding to > the original access type. > > At this moment we're throwing a page-fault exception for both cases. We > want the second case to throw an access-fault exception. PMA stands for > "Physical Memory Access", i.e. the read/write/execute bits of the PTE. > PMP is an optional physical-memory protection scheme. Both are related > to a PTE permission to be read/write/executed, regardless of other > failures like address misaligned/wrong operation size.
Are you sure that's what a PMA check is ? Section 3.6 seems to me to be describing something else, where the hardware uses some combination of hardwired info and unspecified platform-specific registers to determine whether the physical address is to somewhere that supports particular access widths, atomic insns, cacheability, and ability to read, write or exec. I can't see where in the spec it defines what's supposed to happen if the page-table-entry read fails because it's to an invalid physical address, so presumably that's just a subtype of "failed a PMA check". (3.6.1 has a note that supports that reading, where it says that previous spec versions had a "vacant region" concept, presumably corresponding to our "decode error", but that these are now treated as I/O regions that have none of r/w/x access permissions.) In that case the riscv page table walk code should: - fail with page-fault exception for "pte.a field is zero" (and do not attempt a load from physaddr 0) - otherwise, do the load, and report any kind of failure of the load as an access-fault exception Do you implement emulation of these platform-specific PMA registers? If so, those sound to me like they should be some extra level of checks that your page-table-walk code does before it does the real physical-address load, similar to how you do the PMP checks. It doesn't sound to me quite the same as the return value from QEMU's address_space_ld* functions, which is more the case of "the guest misconfigured the PMA registers and did an access that passed the PMA checks but which the actual device rejected". thanks -- PMM
