Skip to content
Draft
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
1 change: 1 addition & 0 deletions src/priv/preface.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@ h|Extension h|Version
|ext:smstateen[] |1.0
|ext:smcsrind[] |1.0
|ext:smepmp[] |1.0
|ext:smpmpmt[] |1.0
|ext:smcntrpmf[] |1.0
|ext:smrnmi[] |1.0
|ext:smcdeleg[] |1.0
Expand Down
1 change: 1 addition & 0 deletions src/priv/sm.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ Its contents are normative, but the presentation might appear disjoint.
include::smstateen.adoc[]
include::smcsrind.adoc[]
include::smepmp.adoc[]
include::smpmpmt.adoc[]
include::smcntrpmf.adoc[]
include::smrnmi.adoc[]
include::smcdeleg.adoc[]
Expand Down
58 changes: 58 additions & 0 deletions src/priv/smpmpmt.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
[[ext:smpmpmt]]
=== ext:smpmpmt[] PMP-based Memory Types Extension

The extlink:svpbmt[] extension provides a mechanism to control memory
attributes at the granularity of a virtual-memory page.
Unfortunately, Svpbmt is only available for RV64, and only then when
page-based virtual memory is in effect.

The Smpmpmt extension provides a mechanism analogous to Svpbmt but associated
with the PMP registers rather than page-table entries.
A new WARL field, MT (Memory Type), is added in the unallocated bits 6--5 in
each PMP configuration register.
The MT field of the lowest-numbered PMP register that an access matches,
following the existing PMP address-matching rules, overrides the PMAs for
that access.
If an access matches no PMP registers, or if the MT field of the matching PMP
register contains the value PMA, then the access proceeds as though the
Smpmpmt extension were not implemented.

NOTE: The permissions checks associated with a PMP register are unrelated to
whether an access is considered to match a PMP register.
For example, even though a PMP register with its L bit clear does not enforce
its permissions checks on M-mode accesses, M-mode accesses within the
address range of that PMP register are still considered to match.
Hence, that PMP register's MT field takes effect for matching M-mode accesses.

The MT field is encoded as shown in <<ext:svpbmt>>.
The encoding is identical to that of the PBMT field, and the meaning of each
type is as specified by the Svpbmt extension.
Refer to that specification for the semantics of each type.

[[pmpmt]]
.Encodings for MT field
[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
|===
|Mode |Value |Requested Memory Attributes
|PMA +
NC +
IO +
-
|0 +
1 +
2 +
3
|None +
Non-cacheable, idempotent, weakly-ordered (RVWMO), main memory +
Non-cacheable, non-idempotent, strongly-ordered (I/O ordering), I/O +
_Reserved for future standard use_
|===

The PMP-based memory types compose with the page-based memory types as follows.
First, the PMP-based memory types override the PMAs, producing an intermediate
set of attributes.
Then, supervisor-level memory attributes (e.g. the page-based attributes
described in the Svpbmt specification) override the intermediate attributes to
produce a final set of attributes.
As with Svpbmt, it is implementation-defined whether PMP-based memory types
override additional PMAs not explicitly listed in <<ext:svpbmt>>.
Loading