Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update PMP spec to use "memory operation" #1434

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions src/cmo.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -337,8 +337,16 @@ _This specification assumes that the above constraints will typically be met for
main memory regions and may be met for certain I/O regions._
====

Additionally, for the purposes of PMP and PMA checks, the access size of a CMO
instruction equals the size of the cache block accessed by the instruction.
[NOTE]
====
The access size for CMO instructions is equal to the size of the cache
block, however in some cases that access can be decomposed into multiple
memory operations. PMP checks are applied to each memory operation
independently. For example a 64-byte *cbo.zero* that spans two 32-byte PMP
regions would succeed if it was decomposed into two 32-byte memory operations
(and the PMP access control bits are the same in both regions), but if
performed as a single 64-byte memory operation it would cause an access fault.
====

The Zicboz extension introduces an additional supported access type PMA for
cache-block zero instructions. Main memory regions are required to support
Expand Down
46 changes: 24 additions & 22 deletions src/machine.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3234,47 +3234,49 @@ R/W/X permissions apply only to S and U modes.

===== Priority and Matching Logic

On some implementations, misaligned loads, stores, and instruction
fetches may be decomposed into multiple memory operations, some of which may
succeed before an access-fault exception occurs, as described in the RVWMO
specification. PMP checking is performed on each memory operation independently.
In particular, a portion of a misaligned store that passes
the PMP check may become visible, even if another portion fails the PMP check.
The same behavior may manifest for stores wider than XLEN bits (e.g., the
FSD instruction in RV32D), even when the store address is naturally aligned.

PMP entries are statically prioritized. The lowest-numbered PMP entry
that matches any byte of an access determines whether that access
succeeds or fails. The matching PMP entry must match all bytes of an
access, or the access fails, irrespective of the L, R, W, and X bits.
that matches any byte of a memory operation determines whether that operation
succeeds or fails. The matching PMP entry must match all bytes of a memory
operation, or the operation fails, irrespective of the L, R, W, and X bits.
For example, if a PMP entry is configured to match the four-byte range
`0xC`–`0xF`, then an 8-byte access to the range `0x8`–`0xF` will fail,
assuming that PMP entry is the highest-priority entry that matches those
addresses.

If a PMP entry matches all bytes of an access, then the L, R, W, and X
bits determine whether the access succeeds or fails. If the L bit is
clear and the privilege mode of the access is M, the access succeeds.
If a PMP entry matches all bytes of a memory operation, then the L, R, W, and X
bits determine whether the operation succeeds or fails. If the L bit is
clear and the privilege mode of the access is M, the operation succeeds.
Otherwise, if the L bit is set or the privilege mode of the access is S
or U, then the access succeeds only if the R, W, or X bit corresponding
or U, then the operation succeeds only if the R, W, or X bit corresponding
to the access type is set.

If no PMP entry matches an M-mode access, the access succeeds. If no PMP
entry matches an S-mode or U-mode access, but at least one PMP entry is
implemented, the access fails.
If no PMP entry matches an M-mode memory operation, the operation succeeds.
If no PMP entry matches an S-mode or U-mode memory operation, but at least
one PMP entry is implemented, the operation fails.

[NOTE]
====
If at least one PMP entry is implemented, but all PMP entries’ A fields
are set to OFF, then all S-mode and U-mode memory accesses will fail.
====

Failed accesses generate an instruction, load, or store access-fault
Failed memory operations generate an instruction, load, or store access-fault
exception. Note that a single instruction may generate multiple
accesses, which may not be mutually atomic. An access-fault exception is
generated if at least one access generated by an instruction fails,
though other accesses generated by that instruction may succeed with
memory operations, which may not be mutually atomic. An access-fault exception
is generated if at least one memory operation generated by an instruction fails,
though other memory operations generated by that instruction may succeed with
visible side effects. Notably, instructions that reference virtual
memory are decomposed into multiple accesses.
memory are decomposed into multiple memory operations.

On some implementations, misaligned loads, stores, and instruction
fetches may also be decomposed into multiple accesses, some of which may
succeed before an access-fault exception occurs. In particular, a
portion of a misaligned store that passes the PMP check may become
visible, even if another portion fails the PMP check. The same behavior
may manifest for stores wider than XLEN bits (e.g., the FSD instruction
in RV32D), even when the store address is naturally aligned.

[[pmp-vmem]]
==== Physical Memory Protection and Paging
Expand Down
Loading