Add the Svnapot standard extension

2 files changed, 161 insertions, 17 deletions

diff --git a/src/priv-preface.tex b/src/priv-preface.tex
index 8e5e4e1..2cc43c9 100644
--- a/src/priv-preface.tex
+++ b/src/priv-preface.tex
@@ -9,11 +9,12 @@ following modules:
   \centering
   \begin{tabular}{|c|l|c|}
     \hline
-    Module             & Version  & Status\\
+    Module                & Version  & Status\\
     \hline
-    \em Machine ISA    & \em 1.12 & \em Frozen \\
-    \em Supervisor ISA & \em 1.12 & \em Frozen \\
-    \em Hypervisor ISA & \em 1.0  & \em Frozen \\
+    \em Machine ISA       & \em 1.12 & \em Frozen \\
+    \em Supervisor ISA    & \em 1.12 & \em Frozen \\
+    \em Svnapot Extension & \em 1.0  & \em Frozen \\
+    \em Hypervisor ISA    & \em 1.0  & \em Frozen \\
     \hline
   \end{tabular}
 \end{table}
@@ -80,6 +81,8 @@ Additionally, the following compatible changes have been made since version
 \item Clarified that bare S-mode need not support the SFENCE.VMA instruction.
 \item Specified relaxed constraints for implicit reads of non-idempotent
   regions.
+\item Added the Svnapot Standard Extension, along with the N bit in
+  Sv39, Sv48, and Sv57 PTEs
 \end{itemize}
 
 Finally, the hypervisor architecture proposal has been extensively revised.
diff --git a/src/supervisor.tex b/src/supervisor.tex
index 0d472f2..cf77bf6 100644
--- a/src/supervisor.tex
+++ b/src/supervisor.tex
@@ -1875,8 +1875,9 @@ quickly distinguish user and supervisor address regions.
 \begin{figure*}[h!]
 {\footnotesize
 \begin{center}
-\begin{tabular}{@{}Y@{}Y@{}Y@{}Y@{}Fcccccccc}
-\instbitrange{63}{54} &
+\begin{tabular}{cY@{}Y@{}Y@{}Y@{}Fcccccccc}
+\instbit{63} &
+\instbitrange{62}{54} &
 \instbitrange{53}{28} &
 \instbitrange{27}{19} &
 \instbitrange{18}{10} &
@@ -1890,7 +1891,8 @@ quickly distinguish user and supervisor address regions.
 \instbit{1} &
 \instbit{0} \\
 \hline
-\multicolumn{1}{|c|}{\it Reserved} &
+\multicolumn{1}{|c|}{N} &
+\multicolumn{1}{c|}{\it Reserved} &
 \multicolumn{1}{c|}{PPN[2]} &
 \multicolumn{1}{c|}{PPN[1]} &
 \multicolumn{1}{c|}{PPN[0]} &
@@ -1904,7 +1906,7 @@ quickly distinguish user and supervisor address regions.
 \multicolumn{1}{c|}{R} &
 \multicolumn{1}{c|}{V} \\
 \hline
-10 & 26 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
+1 & 9 & 26 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
 \end{tabular}
 \end{center}
 }
@@ -1919,7 +1921,11 @@ always be aligned to a page boundary.  The physical page number of the
 root page table is stored in the {\tt satp} register's PPN field.
 
 The PTE format for Sv39 is shown in Figure~\ref{sv39pte}.  Bits 9--0
-have the same meaning as for Sv32.  Bits 63--54 are reserved
+have the same meaning as for Sv32.
+Bit 63 is reserved for use by the Svnapot extension in
+Chapter~\ref{svnapot}.  If Svnapot is not implemented, bit 63 remains
+reserved and must be zeroed by software for forward compatibility,
+or else a page-fault exception is raised.  Bits 62--54 are reserved
 for future standard use and, until their use is defined by some standard
 extension, must be zeroed by software for forward compatibility.
 If any of these bits are set, a page-fault exception is raised.
@@ -2027,8 +2033,9 @@ is untranslated.
 \begin{figure*}[h!]
 {\footnotesize
 \begin{center}
-\begin{tabular}{@{}Y@{}Y@{}Y@{}Y@{}Y@{}Fcccccccc}
-\instbitrange{63}{54} &
+\begin{tabular}{cF@{}F@{}F@{}F@{}F@{}Fcccccccc}
+\instbit{63} &
+\instbitrange{62}{54} &
 \instbitrange{53}{37} &
 \instbitrange{36}{28} &
 \instbitrange{27}{19} &
@@ -2043,7 +2050,8 @@ is untranslated.
 \instbit{1} &
 \instbit{0} \\
 \hline
-\multicolumn{1}{|c|}{\it Reserved} &
+\multicolumn{1}{|c|}{N} &
+\multicolumn{1}{c|}{\it Reserved} &
 \multicolumn{1}{c|}{PPN[3]} &
 \multicolumn{1}{c|}{PPN[2]} &
 \multicolumn{1}{c|}{PPN[1]} &
@@ -2058,7 +2066,7 @@ is untranslated.
 \multicolumn{1}{c|}{R} &
 \multicolumn{1}{c|}{V} \\
 \hline
-10 & 17 & 9 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
+1 & 9 & 17 & 9 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
 \end{tabular}
 \end{center}
 }
@@ -2166,8 +2174,9 @@ is untranslated.
 \begin{figure*}[h!]
 {\footnotesize
 \begin{center}
-\begin{tabular}{@{}Y@{}F@{}F@{}F@{}F@{}F@{}Wcccccccc}
-\instbitrange{63}{54} &
+\begin{tabular}{c@{}Y@{}F@{}F@{}F@{}F@{}F@{}Wcccccccc}
+\instbit{63} &
+\instbitrange{62}{54} &
 \instbitrange{53}{46} &
 \instbitrange{45}{37} &
 \instbitrange{36}{28} &
@@ -2183,7 +2192,8 @@ is untranslated.
 \instbit{1} &
 \instbit{0} \\
 \hline
-\multicolumn{1}{|c|}{\it Reserved} &
+\multicolumn{1}{|c|}{N} &
+\multicolumn{1}{c|}{\it Reserved} &
 \multicolumn{1}{c|}{PPN[4]} &
 \multicolumn{1}{c|}{PPN[3]} &
 \multicolumn{1}{c|}{PPN[2]} &
@@ -2199,7 +2209,7 @@ is untranslated.
 \multicolumn{1}{c|}{R} &
 \multicolumn{1}{c|}{V} \\
 \hline
-10 & 8 & 9 & 9 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
+1 & 9 & 8 & 9 & 9 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
 \end{tabular}
 \end{center}
 }
@@ -2220,3 +2230,134 @@ insufficiently aligned.
 The algorithm for virtual-to-physical address translation is the same
 as in Section~\ref{sv32algorithm}, except LEVELS equals 5 and PTESIZE
 equals 8.
+
+\chapter{``Svnapot'' Standard Extension for NAPOT Translation Contiguity, Version 0.1}
+\label{svnapot}
+
+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
+size.
+
+\begin{table*}[h!]
+\begin{center}
+\begin{tabular}{|c|c||l|c|}
+\hline
+i        & $pte.ppn[i]$      & Description              & $pte.napot\_bits$ \\
+\hline
+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
+\end{tabular}
+\end{center}
+\caption{Page table entry encodings when $pte$.N=1}
+\label{ptenapot}
+\end{table*}
+
+NAPOT PTEs behave identically to non-NAPOT PTEs within the address-translation
+algorithm in Section~\ref{sv32algorithm}, except that:
+\begin{itemize}
+  \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[i][pte.napot\_bits-1:0]$.  If the encoding in $pte$ is
+    reserved according to Table~\ref{ptenapot}, then a page-fault exception
+    must be raised.
+  \item Implicit reads of NAPOT page table entries 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
+    $vpn[0][pte.napot\_bits-1:0]$, for any or all $j$ such that
+    ${j[8:napot\_bits]}={i[8:napot\_bits]}$, all for the address space identified
+    in {\em satp} as loaded by step 0.
+\end{itemize}
+
+\begin{commentary}
+  The motivation for a NAPOT PTE is that it can be cached in a TLB as one or
+  more entries representing the contiguous region as if it were a single
+  (large) page covered by a single translation.  This compaction can help
+  relieve TLB pressure in some scenarios.  The encoding is designed to fit
+  within the pre-existing Sv39, Sv48, and Sv57 PTE formats so as not to disrupt
+  existing implementations or designs that choose not to implement the scheme.
+  It is also designed so as not to complicate the definition of the
+  address-translation algorithm.
+
+  The address translation cache abstraction captures the behavior that would result from the creation
+  of a single TLB entry covering the entire NAPOT region.  It is also designed
+  to be consistent with implementations that support NAPOT PTEs by splitting
+  the NAPOT region into TLB entries covering any smaller power-of-two region
+  sizes.  For example, a 64KiB NAPOT PTE might trigger the creation of 16
+  standard 4KiB TLB entries, all with contents generated from the NAPOT PTE
+  (even if the PTEs for the other 4KiB regions have different contents).
+
+  In typical usage scenarios, NAPOT PTEs in the same region will have the same
+  attributes, same PPNs, and same values for bits 5--0.  RSW remains reserved
+  for supervisor software control.  It is the responsibility of the OS and/or
+  hypervisor to configure the page tables in such a way that there are no
+  inconsistencies between NAPOT PTEs and other NAPOT or non-NAPOT PTEs that
+  overlap the same address range.  If an update needs to be made, the OS
+  generally should first mark all of the PTEs invalid, then issue SFENCE.VMA
+  instruction(s) covering all 4KiB regions within the range (either via a
+  single SFENCE.VMA with {\em rs1}={\tt x0}, or with multiple SFENCE.VMA
+  instructions with {\em rs1}$\neq${\tt x0}), then update the PTE(s), as
+  described in Section~\ref{sec:sfence.vma}, unless any inconsistencies are
+  known to be benign.  If any inconsistencies do exist, then the effect is the
+  same as when SFENCE.VMA is used incorrectly: one of the translations will be
+  chosen, but the choice is unpredictable.
+
+  When updating a region of NAPOT PTEs all at once, it is recommended that
+  software continue to follow the idiom in Figure~\ref{consecutive_sfences}
+  in which no more than one add and one branch instruction is inserted between
+  consecutive SFENCE.VMA instructions.
+
+  If an implementation chooses to use a NAPOT PTE (or cached version thereof),
+  it might not consult the PTE directly specified by the algorithm in
+  Section~\ref{sv32algorithm} at all.  Therefore, the D and A bits may not be
+  identical across all mappings of the same address range even in typical use
+  cases  The operating system must query all NAPOT aliases of a page to
+  determine whether that page has been accessed and/or is dirty.  If the OS
+  manually sets the A and/or D bits for a page, it is recommended that the OS
+  also set the A and/or D bits for other NAPOT aliases as appropriate in order
+  to avoid unnecessary traps.
+
+  Just as with normal PTEs, TLBs are permitted to cache NAPOT PTEs whose V
+  (Valid) bit is clear.
+
+  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:
+
+  \begin{center}\em
+  \begin{tabular}{|c|c||l|c|}
+  \hline
+  i        & $pte.ppn[i]$      & Description                & $pte.napot\_bits$ \\
+  \hline
+  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
+  \end{tabular}
+  \end{center}
+
+  In such a case, an implementation may or may not support all options.  The
+  discoverability mechanism for this extension would be extended to allow
+  system software to determine which sizes are supported.
+
+  Other sizes may remain deliberately excluded, so that PPN bits not being
+  used to indicate a valid NAPOT region size (e.g., the least-significant bit
+  of $pte.ppn[i]$) may be repurposed for other uses in the future.
+
+  However, in case finer-grained intermediate page size support proves not to
+  be useful, we have chosen to standardize only 64KiB support as a first step.
+\end{commentary}