Merge branch 'Svpbmt' into Svinval

1 files changed, 44 insertions, 41 deletions

diff --git a/src/supervisor.tex b/src/supervisor.tex
index 84523e7..50a7f7f 100644
--- a/src/supervisor.tex
+++ b/src/supervisor.tex
@@ -2136,7 +2136,7 @@ equals 8.
 \chapter{``Svnapot'' Standard Extension for NAPOT Translation Contiguity, Version 0.1}
 \label{svnapot}
 
-In Sv39, Sv48, and Sv57, when Svnapot is enabled and a PTE has N=1, the PTE represents a
+In Sv39, Sv48, and Sv57, when a PTE has N=1, the PTE represents a
 translation that is part of a range of contiguous virtual-to-physical
 translations with the same values for PTE bits 5--0.  Such ranges must be of a
 naturally aligned power-of-2 (NAPOT) granularity larger than the base page
@@ -2155,44 +2155,44 @@ size.
 
 \begin{table*}[h!]
 \begin{center}
-\begin{tabular}{|c|c||c|c|}
+\begin{tabular}{|c|c||l|c|}
 \hline
-N & $pte.ppn[i]$      & $pte.napot\_bits$ & Meaning if $i=0$         \\
+i        & $pte.ppn[i]$      & Description              & $pte.napot\_bits$ \\
 \hline
-0 & {\tt y~yyyy~yyyy} & 0                 &  Non-NAPOT 4KiB PTE      \\
-1 & {\tt y~yyyy~1000} & 4                 &  64KiB contiguous region \\
-1 & {\em other}       & $-$               &  {\em Reserved for standard use} \\
+0        & {\tt x~xxxx~xxx1} & {\em Reserved}           & $-$ \\
+0        & {\tt x~xxxx~xx1x} & {\em Reserved}           & $-$ \\
+0        & {\tt x~xxxx~x1xx} & {\em Reserved}           & $-$ \\
+0        & {\tt x~xxxx~1000} & 64 KiB contiguous region & 4   \\
+0        & {\tt x~xxxx~0xxx} & {\em Reserved}           & $-$ \\
+$\geq 1$ & {\tt x~xxxx~xxxx} & {\em Reserved}           & $-$ \\
 \hline
-\multicolumn{4}{l}{{\tt y}: subset of PPN used for address translation} \\
 \end{tabular}
 \end{center}
-\caption{NAPOT Contiguous Translation Encodings}
+\caption{Page table entry encodings when $pte$.N=1}
 \label{ptenapot}
 \end{table*}
 
-The list of currently supported NAPOT PTE encodings and the definition of {\em
-napot\_bits} are shown in Table~\ref{ptenapot}.  Currently, NAPOT encodings are
-only supported for 4KiB leaf PTEs.
-
 \begin{commentary}
   Depending on need, the NAPOT scheme may be extended to other intermediate
   page sizes and/or to other levels of the page table in the future.  The
   encoding is designed to accommodate other NAPOT sizes should that need
-  arise.  For example, the addition of 16KiB and 256KiB support would look
-  as follows:
+  arise.  For example:
 
   \begin{center}\em
-  \begin{tabular}{|c|c||c|c|}
+  \begin{tabular}{|c|c||l|c|}
   \hline
-  N & $pte.ppn[i]$      & $pte.napot\_bits$ & Meaning if $i=0$         \\
+  i        & $pte.ppn[i]$      & Description                & $pte.napot\_bits$ \\
   \hline
-  0 & {\tt y~yyyy~yyyy} & 0                 &  Non-NAPOT 4KiB PTE      \\
-  1 & {\tt y~yyyy~yy10} & 2                 &  16KiB contiguous region \\
-  1 & {\tt y~yyyy~1000} & 4                 &  64KiB contiguous region \\
-  1 & {\tt y~yy10~0000} & 6                 &  256KiB contiguous region \\
-  1 & {\em other}       & $-$               &  {\em Reserved for future standard use} \\
+  0        & {\tt x~xxxx~xxx1} & 8 KiB contiguous region    & 1 \\
+  0        & {\tt x~xxxx~xx10} & 16 KiB contiguous region   & 2 \\
+  0        & {\tt x~xxxx~x100} & 32 KiB contiguous region   & 3 \\
+  0        & {\tt x~xxxx~1000} & 64 KiB contiguous region   & 4 \\
+  0        & {\tt x~xxx1~0000} & 128 KiB contiguous region  & 5 \\
+  ...      & ...               & ...                        & ... \\
+  1        & {\tt x~xxxx~xxx1} & 4 MiB contiguous region    & 1 \\
+  1        & {\tt x~xxxx~xx10} & 8 MiB contiguous region    & 2 \\
+  ...      & ...               & ...                        & ... \\
   \hline
-  \multicolumn{4}{l}{{\tt y}: subset of PPN used for address translation} \\
   \end{tabular}
   \end{center}
 
@@ -2215,9 +2215,9 @@ algorithm in Section~\ref{sv32algorithm}, except that:
   \item If the encoding in $pte$ is valid according to Table~\ref{ptenapot},
     then instead of returning the original value of $pte$, implicit reads of a
     NAPOT PTE return a copy of $pte$ in which $pte.ppn[pte.napot\_bits-1:0]$ is
-    replaced by $vpn[0][pte.napot\_bits-1:0]$
-  \item If the encoding in $pte$ is {\em reserved} according to
-    Table~\ref{ptenapot}, then a page-fault exception must be raised.
+    replaced by $vpn[i][pte.napot\_bits-1:0]$.  If the encoding in $pte$ is
+    {\em reserved} according to Table~\ref{ptenapot}, then a page-fault
+    exception must be raised.
   \item Implicit reads of NAPOT page table may create address-translation cache
     entries mapping $a + va.vpn[j] \times \textrm{PTESIZE}$ to a copy of $pte$
     in which $pte.ppn[pte.napot\_bits-1:0]$ is replaced by
@@ -2274,7 +2274,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
   types or accesses to invalid physical memory regions trigger page faults.
 \end{commentary}
 
-\chapter{``Svpbmt'' Standard Extension for Page-Based Memory Attributes, Version 0.1}
+\chapter{``Svpbmt'' Standard Extension for Page-Based Memory Types, Version 0.1}
 \label{svpbmt}
 
 {\bf Warning! This draft specification is likely to change before being
@@ -2288,11 +2288,11 @@ pages.  The encoding for the PBMT bits is captured in Table~\ref{pbmt}.
 \begin{center}
 \begin{tabular}{|r|l|}
 \hline
-Value  & Page-Based Memory Attributes \\
+Value  & Requested Memory Attributes \\
 \hline
 0      & None \\
 1      & Non-cacheable, idempotent, weakly-ordered (RVWMO or RVTSO), main memory \\
-2      & Non-cacheable, non-idempotent, strongly-ordered (channel 0), I/O \\
+2      & Non-cacheable, non-idempotent, strongly-ordered (I/O ordering), I/O \\
 3      & {\em Reserved for future standard use} \\
 \hline
 \end{tabular}
@@ -2310,14 +2310,19 @@ can be overridden.
 For non-leaf PTEs, bits 62--61 are reserved for future standard use and must be
 cleared by software for forward compatibility.
 
-If the underlying physical memory attribute for a page is I/O, then accesses to
-that page with PBMT=1 will obey RVWMO or RVTSO rather than I/O strong ordering
-rules, and accesses to such pages are considered main memory rather than I/O
-for the purposes of FENCE, {\em.aq}, and {\em.rl}.
+If the underlying physical memory attribute for a page is main memory and
+the page has PBMT=0 or PBMT=1, or if the underlying physical memory attribute
+for a page is I/O and the page has PBMT=2, then accesses to that page obey the
+same memory ordering rules normally applied to accesses to that physical page.
+
+If the underlying physical memory attribute for a page is I/O, and the page has
+PBMT=1, then then accesses to that page obey RVWMO.  Accesses to such pages are
+considered main memory rather than I/O for the purposes of FENCE, {\em.aq}, and
+{\em.rl}.
 
-If the underlying physical memory attribute for a page is main memory, then
-accesses to that page via a page table entry with PBMT=2 obey strong channel 0
-ordering with respect to other accesses to physical main memory and to other
+If the underlying physical memory attribute for a page is main memory, and the
+page has PBMT=2, then accesses to that page obey strong channel 0 I/O ordering
+rules with respect to other accesses to physical main memory and to other
 accesses to pages with PBMT=2.  Furthermore, accesses to such pages are
 considered I/O rather than main memory for the purposes of FENCE, {\em.aq}, and
 {\em.rl}.
@@ -2326,12 +2331,10 @@ With Svpbmt enabled, it is possible for multiple virtual aliases of the same
 physical page to exist simultaneously with different memory attributes.  It is
 also possible for a U-mode or S-mode mapping through a PTE with Svpbmt enabled
 to observe different memory attributes for a given region of physical memory
-than a concurrent access to the same page performed by M-mode or when {\tt
-satp}.MODE=Bare.  If accesses are performed simultaneously to the same region
-of memory using different attributes, there may be a loss of coherence and/or
-of normal RVWMO, RVTSO, or I/O ordering semantics.  In such cases,
-platform-specific mechanisms must be used to restore corrent coherence and
-memory ordering.
+than a concurrent access to the same page performed by M-mode or when
+MODE=Bare.  In such cases, there may be a loss of coherence and/or of normal
+RVWMO, RVTSO, or I/O ordering semantics, and platform-specific mechanisms must
+be used to restore coherence and memory ordering.
 
 \begin{commentary}
 For example, a cacheable access may be issued at the same time as a