[QUESTION] Why should an access that spans two PMP regions fail ?

[iamkarthikbk]

Hi. I am trying to understand this section of the spec, which describes the priority and matching logic. If I understand it correctly, a memory accesses hitting two PMP regions (that may or may not have the same permission bits in the corresponding pmpcfg) fail. Can someone please help me with why it is this way?

[aswaterman]

The current definition simplifies the logic to implement the PMP check. An alternative definition that allowed an access to span two regions would've been logically consistent, but it would've been more expensive to implement.

[iamkarthikbk]

That makes sense. Can you please help me understand what should happen in the following scenario ?

A PMP entry (say 0) is configured to match the eight-byte range 0x8-0xF allowing all accesses and a second (lower priority) PMP entry (say 1) is configured to match the four-byte range 0xC-0xF disallowing all accesses. The hart encounters an 8-byte access to the range 0x8-0xF - similar to this example.

If I perform address matching as base_addr + access_sz, pmp0 is the matching entry, and it matches all bytes of the access. Therefore the L, R, W, X bits determine whether the access succeeds or fails. However, the spec does not restrict me to perform address matching this way. If I consider pmp1 to be the matching PMP, then the access fails as it does not match all bytes of the access.

Can you please clarify what is "the matching pmp" in the example linked above ?

[stnolting]

I think the term "hitting two regions" might be misleading!?

If an access address falls into an address range that is specified by two PMP regions (potentially having different R/W/X setting), the higher-prioritized PMP region will define if that access fails or succeeds, right?

An alternative definition that allowed an access to span two regions would've been logically consistent, but it would've been more expensive to implement.

So for a 32-bit core this would be something like this, right?

0x00  |              |
0x04  | PMP region 0 |  \
      +--------------+  |-- Accessed address (word) at 0x06, *spanning* two regions -> FAIL
0x08  | PMP region 1 |  /
0x0C  |              |

But wouldn't this raise a misaligned address exception, anyway?

[iamkarthikbk]

I think the term "hitting two regions" might be misleading!?

Agreed, it should be "spanning two regions".

If an access address falls into an address range that is specified by two PMP regions (potentially having different R/W/X setting), the higher-prioritized PMP region will define if that access fails or succeeds, right?

I think this depends on how you perform address matching. The spec doesn't restrict me to check (base address + size).

An alternative definition that allowed an access to span two regions would've been logically consistent, but it would've been more expensive to implement.

So for a 32-bit core this would be something like this, right?

0x00  |              |
0x04  | PMP region 0 |  \
      +--------------+  |-- Accessed address (word) at 0x06, *spanning* two regions -> FAIL
0x08  | PMP region 1 |  /
0x0C  |              |

But wouldn't this raise a misaligned address exception, anyway?

True, and the change to rd will depend on how I handle a misaligned address exception, agreed. What happens in a 64-bit system - for the example I described in my previous comment ? What happens in RV128 ? Will it come with an lq/sq ? Would it make sense to say that the minimum PMP granularity should be XLEN or data-bus width instead of 4 bytes?

[allenjbaum]

(this is a hot button for me, so this is more information than you wanted to know)

This particular example is pretty clear. There is an aligned address range and an aligned access to it. The access falls completely into that range, so it is a complete match - not a partial match. It matches the highest priority PMP entry, therefore the entire access uses that entry to determine legality.

IF this were an RV32 access was it was broken up into 2 4byte accesses (in either order), the same rules apply. Individually, each access is fully contained within the configuration of the higher priority entry, so it takes precedence.

Where it gets more interesting is when an access isn't completely contained within one entry, e.g. FSD in RV32 when it is 4B aligned, not 8B aligned. There the spec is a bit more vague, and there are multiple legal outcomes.

• misaligned accesses not supported: trap with misaligned exception
• misaligned accesses supported, access not broken up: trap with access fault
• misaligned accesses supported, access broken up, lower address accessed first: store the first half, access fault on the second
• misaligned accesses supported, access broken up, higher address accessed first: access fault on the higher, store nothing There are more cases (e.g. both halves of the access will cause an exception, for different reasons - which do you report in xcause, and in xtval?)

This example gives SAIL and ACTs more than a little grief, because there is nothing in the spec that

• requires the order accesses will be made,
• requires that the order even be deterministic (e.g. a high-end implementation launches both accesses in parallel with no guarantee which will start or finish first)
• requires that support for misaligned accesses means it will never trap with a misaligned exception cause (e.g. both accesses are not in the TLB, so the implementation just punts) Those scenarios aren't likely, but I think there are all legal (and ACTs are supposed to test legality, not likelihood). To properly test this, ACT will need to be given implementation option descriptions
  • which are not extensions, though some (now) have extension-like names (e.g. Zicclsm) examples of nameless architectural options that have bearing on this case are: order of misaligned accesses, whether misaligned accesses are broken up, priority order of exception causes Needless to say, none of this is currently implemented.

On Wed, Dec 20, 2023 at 2:01 AM Karthik B K @.***> wrote:

I think the term "hitting two regions" might be misleading!?

Agreed, it should be "matching/spanning two regions".

If an access address falls into an address range that is specified by two PMP regions (potentially having different R/W/X setting), the higher-prioritized PMP region will define if that access fails or succeeds, right?

I think this depends on how you perform address matching. The spec doesn't restrict me to check (base address + size).

An alternative definition that allowed an access to span two regions would've been logically consistent, but it would've been more expensive to implement.

So for a 32-bit core this would be something like this, right?

0x00 | | 0x04 | PMP region 0 | \ +--------------+ |-- Accessed address (word) at 0x06, spanning two regions -> FAIL 0x08 | PMP region 1 | / 0x0C | |

But wouldn't this raise a misaligned address exception, anyway?

True, and the change to rd will depend on how I handle a misaligned address exception, agreed. What happens in a 64-bit system - for the example I described in my previous comment ? What happens in RV128 ? Will it come with an lq/sq ? Would it make sense to say that the minimum PMP granularity should be XLEN or data-bus width instead of 4 bytes?

— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/1179#issuecomment-1864186493, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJWJRKUY2CCSQKYL2UDYKKZQBAVCNFSM6AAAAABA4NZYGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRUGE4DMNBZGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>