Merge branch 'main' into kersten1-patch-1

Author: kersten1

src/j-st-ext.adoc

@@ -2785,7 +2785,7 @@ Specific supported values for this PMA are represented by MAG__NN__, e.g.,
 MAG16 indicates the misaligned atomicity granule is at least 16 bytes.
 
 The misaligned atomicity granule PMA applies only to AMOs, loads and stores
-defined in the base ISAs, and loads and stores of no more than MXLEN bits
+defined in the base ISAs, and loads and stores of no more than XLEN bits
 defined in the F, D, and Q extensions.
 For an instruction in that set, if all accessed bytes lie within the same
 misaligned atomicity granule, the instruction will not raise an exception for

src/machine.adoc

@@ -239,7 +239,7 @@ visible memory). Any other hart will therefore observe the load as
 performing before the store.
 
 Consider the <<litms_sb_forward>>. When running this program on an implementation with
-store buffers, it is possible to arrive at the final outcome a0=1, `a1=0, a2=1, a3=0` as follows:
+store buffers, it is possible to arrive at the final outcome `a0=1, a1=0, a2=1, a3=0` as follows:
 
 [[litms_sb_forward]]
 .A store buffer forwarding litmus test (outcome permitted)
@@ -295,7 +295,7 @@ Call this "Rule X". Then we get the following:
 preceded (d), then (d) would be required to return the value 1. (This is
 a perfectly legal execution; it's just not the one in question)
 * (e) precedes (f): by rule X
-* (f) precedes (h): by rule <<overlapping-ordering, 4]>>
+* (f) precedes (h): by rule <<overlapping-ordering, 4>>
 * (h) precedes (a): by the load value axiom, as above.
 
 The global memory order must be a total order and cannot be cyclic,

src/mm-eplan.adoc

@@ -1,10 +1,10 @@
 [colophon]
 = Preface
 
-[.big]*_Preface to Version 20240829_*
+[.big]*_Preface to Version 20241002_*
 
 This document describes the RISC-V privileged architecture. This
-release, version 20240829, contains the following versions of the RISC-V ISA
+release, version 20241002, contains the following versions of the RISC-V ISA
 modules:
 
 [%autowidth,float="center",align="center",cols="^,<,^",options="header",]
@@ -49,7 +49,7 @@ _1.13_ +
 *1.0* +
 *1.0* +
 *1.0* +
-_0.1_ +
+_1.0_ +
 *1.0*
 
 |_Frozen_ +
@@ -70,7 +70,7 @@ _Frozen_ +
 *Ratified* +
 *Ratified* +
 *Ratified* +
-_Draft_ +
+_Frozen_ +
 *Ratified*
 |===
 

src/priv-preface.adoc

@@ -2,7 +2,7 @@
 = The RISC-V Instruction Set Manual: Volume II: Privileged Architecture
 include::../docs-resources/global-config.adoc[]
 :description: Volume II - Privileged Architecture
-:revnumber: 20240829
+:revnumber: 20241002-Ratification-Vote
 //:revremark: Pre-release version
 //development: assume everything can change
 //stable: assume everything could change

src/riscv-privileged.adoc

@@ -185,7 +185,6 @@ include::zfinx.adoc[]
 include::c-st-ext.adoc[]
 include::zc.adoc[]
 include::b-st-ext.adoc[]
-include::j-st-ext.adoc[]
 include::p-st-ext.adoc[]
 include::v-st-ext.adoc[]
 include::scalar-crypto.adoc[]

src/riscv-unprivileged.adoc

@@ -1442,8 +1442,9 @@ Two schemes to manage the A and D bits are defined:
   architecturally. However, updates to the D bit, resulting from an
   explicit store, must be exact (i.e., non-speculative), and observed in
   program order by the local hart. When two-stage address translation is
-  active, updates of the D bit in G-stage PTEs may be performed as a
-  result of speculative updates of the A bit in VS-stage PTEs.          +
+  active, updates to the D bit in G-stage PTEs may be performed by an
+  implicit access to a VS-stage PTE, if the G-stage PTE provides write
+  permission, before any speculative access to the VS-stage PTE.        +
                                                                         +
   The PTE update must appear in the global memory order before the
   memory access that caused the PTE update and before any subsequent

src/supervisor.adoc

@@ -148,6 +148,11 @@ It is worth noting that pointer masking is not applied to `SFENCE.\*`, `HFENCE.*
 
 MPRV and SPVP affect pointer masking as well, causing the pointer masking settings of the effective privilege mode to be applied. When MXR is in effect at the effective privilege mode where explicit memory access is performed, pointer masking does not apply.
 
+[NOTE]
+====
+Note that this includes cases where page-based virtual memory is not in effect; i.e., although MXR has no effect on permissions checks when page-based virtual memory is not in effect, it is still used in determining whether or not pointer masking should be applied.
+====
+
 [NOTE]
 ====
 Cache Management Operations (CMOs) must respect and take into account pointer masking. Otherwise, a few serious security problems can appear, including: