Hi Peter,
On 6/8/2026 9:52 AM, Peter Maydell wrote:
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.)
Sorry taking this long to answer. Yeah, "PMA check" as far as the RISC-V
seems to understand is a combination of a lot of things that includes not
just read/write/exec permissions but also alignment, atomicity, caching
and so on.
All memory accesses failures we're able to detect in the code, aside from the
usual "address not found" error that we can interpret safely as an page fault
(... I think ...), can be considered a PMA error. Which is something that we're
*not* doing at this moment, and this might be an alternative for what I'm
proposing here.
It might come to what you said below: an extra layer of checks that we would
call "PMA". I'll have to think more about it ...
Cheers,
Daniel
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
