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 ?

thanks
-- PMM

Reply via email to