On 6/8/2026 7:08 AM, Peter Maydell wrote:
On Mon, 8 Jun 2026 at 10:47, Daniel Henrique Barboza
<[email protected]> wrote:
On 6/8/2026 6:09 AM, Peter Maydell wrote:
On Tue, 2 Jun 2026 at 20:09, Daniel Henrique Barboza
<[email protected]> wrote:
Hello,
I decided to propose this change after working in a RISC-V gitlab bug
[1]. In my proposed fix [2] I had to make assumptions about
address_space_ld* error return, which is always MEMTX_DECODE_ERROR, to
identify that in that particular scenario this is a permission error.
In RISC-V (and from what I can see other archs like x86) an ACCESS_ERROR
due to mem page permission issues will fire a different fault than other
errors like page not found.
The core logic is on memory_region_access_valid(), which already makes a
distinction between error reasons when we look at the qemu_log_mask()
errors, e.g. this is being characterized as a 'rejected':
if (mr->ops->valid.accepts
&& !mr->ops->valid.accepts(mr->opaque, addr, size, is_write, attrs)) {
qemu_log_mask(LOG_INVALID_MEM, "Invalid %s at addr 0x%" HWADDR_PRIX
", size %u, region '%s', reason: rejected\n",
is_write ? "write" : "read",
addr, size, memory_region_name(mr));
valid.accepts returning false isn't a permissions error, though.
It's for cases like "you tried to do a byte access to this device
that requires 32-bit accesses only". Permissions errors are entirely
in the MMU, and don't appear in the MemTx APIs, which are about
transactions in the fabric outside the MMU. The CPU emulation
catches permissions errors early before it even does the
address_space_ld* call.
What is the equivalent of this in the underlying hardware?
The current error codes are intended to roughly match the AXI
bus SLVERR and DECERR error responses (which are "we were
able to pass this memory transaction to a device, but it
rejected it" and "we weren't able to find the device for
this memory transaction at all").
The valid.accepts callback failing is always "we know the memory
region but it doesn't like this", which is true for all
memory_region_access_valid() failures, so maybe the problem
here is that we return DECODE_ERROR for that case when
we should be returning ACCESS_ERROR ?
This is the end result I'm going for. In patch 1 I changed
memory_region_access_valid()
to return ACCESS_ERROR when the valid.accepts fails, keeping all the
other exit code as DECODE_ERROR. The ACCESS_ERROR will then be propagated
as an error in target/riscv/cpu_helper.c, get_physical_address():
if (riscv_cpu_mxl(env) == MXL_RV32) {
pte = be ? address_space_ldl_be(cs->as, pte_addr, attrs, &res)
: address_space_ldl_le(cs->as, pte_addr, attrs, &res);
} else {
pte = be ? address_space_ldq_be(cs->as, pte_addr, attrs, &res)
: address_space_ldq_le(cs->as, pte_addr, attrs, &res);
}
if (res != MEMTX_OK) {
return TRANSLATE_FAIL;
}
In this particular case 'res' will fail as ACCESS_ERROR if the pte does not have
the right permissions and we can throw the right exception.
But what's the "right exception" here? This is, I think, the code
for "the MMU is loading the page table entry from external memory".
I'm not clear what this has to do with permissions. Generally
"permissions" is a concept that applies to virtual addresses, i.e.
"does the page table for this vaddr say we can access it?", and there's
no concept of permissions for physical addresses. The exception to
that is that you might have something like Arm's "granule protection
table" which does apply permissions to physical accesses, so an
in-guest-memory data structure defines what physical addresses can be
accessed in particular ways. In QEMU we model this as effectively
another level of page tables, so again the check happens before we
do the address_space_ld* call. For risc-v a quick look at the architecture
spec suggests that the Smepmp extension is a bit like this (but
handled via registers rather than guest-memory data structures).
The other kind of check that might need to be done in the MMU before
the load call is "is this physaddr out of range?" (e.g. CPU has
48 bit physaddrs and the L1 PTE specifies a physaddr for the L2 PTE
that is outside the 48 bit range).
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.
Thanks,
Daniel
I would be a bit surprised if the riscv architecture mandated different
MMU errors for "page table entry load failed because the physaddr is not
pointing at any device" vs "page table entry load failed because the
physaddr points at a device and the device rejected it", because it's
really up to the bus specification how clearly it distinguishes these
various kinds of external abort (or even whether it distinguishes them
synchronously vs asynchronously, given the existence of caches), and
usually architecture specifications try not to impose too much on
the implementation.
thanks
-- PMM
