diff options
| -rw-r--r-- | src/priv-preface.tex | 13 | ||||
| -rw-r--r-- | src/supervisor.tex | 179 |
2 files changed, 174 insertions, 18 deletions
diff --git a/src/priv-preface.tex b/src/priv-preface.tex index c25c4f7..0ca835c 100644 --- a/src/priv-preface.tex +++ b/src/priv-preface.tex @@ -10,12 +10,13 @@ modules: \centering \begin{tabular}{|c|l|c|} \hline - Module & Version & Status\\ + Module & Version & Status\\ \hline - \em Machine ISA & \em 1.12 & \em Draft \\ - \em Supervisor ISA & \em 1.12 & \em Draft \\ - \em Hypervisor ISA & \em 0.6 & \em Draft \\ - \em N Extension & \em 1.1 & \em Draft \\ + \em Machine ISA & \em 1.12 & \em Draft \\ + \em Supervisor ISA & \em 1.12 & \em Draft \\ + \em Svnapot Extension & \em 0.1 & \em Draft \\ + \em Hypervisor ISA & \em 0.6 & \em Draft \\ + \em N Extension & \em 1.1 & \em Draft \\ \hline \end{tabular} \end{table} @@ -64,6 +65,8 @@ Additionally, the following compatible changes have been made since version and access-fault exceptions. \item PMP reset values are now platform-defined. \item An additional 48 optional PMP registers have been defined. +\item Added the Svnapot Standard Extension draft, along with the N bit in + Sv39, Sv48, and Sv57 PTEs \item Described the behavior of address-translation caches a little more explicitly. \item Slightly relaxed the atomicity requirement for A and D bit updates diff --git a/src/supervisor.tex b/src/supervisor.tex index d4861dd..d30e619 100644 --- a/src/supervisor.tex +++ b/src/supervisor.tex @@ -1764,8 +1764,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} & @@ -1779,7 +1780,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]} & @@ -1793,7 +1795,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} } @@ -1808,7 +1810,13 @@ 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. + +The N bit indicates that the page represents a +naturally-aligned power-of-two range of contiguous translations, as defined in +the Svnapot extension in Chapter~\ref{svnapot}. + +Bits 62--54 are reserved for future standard use and must be zeroed by software for forward compatibility. If any of these bits are set, a page-fault exception is raised. @@ -1915,8 +1923,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} & @@ -1931,7 +1940,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]} & @@ -1946,7 +1956,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} } @@ -2054,8 +2064,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} & @@ -2071,7 +2082,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]} & @@ -2087,7 +2099,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} } @@ -2108,3 +2120,144 @@ 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{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. +\end{commentary} + +\begin{table*}[h!] +\begin{center} +\begin{tabular}{|c|c||c|c|} +\hline +N & $pte.ppn[i]$ & $pte.napot\_bits$ & Meaning if $i=0$ \\ +\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} \\ +\hline +\multicolumn{4}{l}{{\tt y}: subset of PPN used for address translation} \\ +\end{tabular} +\end{center} +\caption{NAPOT Contiguous Translation Encodings} +\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: + + \begin{center}\em + \begin{tabular}{|c|c||c|c|} + \hline + N & $pte.ppn[i]$ & $pte.napot\_bits$ & Meaning if $i=0$ \\ + \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} \\ + \hline + \multicolumn{4}{l}{{\tt y}: subset of PPN used for address translation} \\ + \end{tabular} + \end{center} + + In such a case, an implementation may or may not support all options, subject + to profile requirements. 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 prove not to + be useful, we have chosen to standardize only 64KiB support as a first step. +\end{commentary} + +NAPOT PTEs behave just like non-NAPOT PTEs do 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[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. + \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 + $vpn[0][pte.napot\_bits-1:0]$, for any or all $j$ such that + $j[9:napot\_bits]=i[9:napot\_bits]$, all for the address space identified + in {\em satp} as loaded by step 0. +\end{itemize} + +\begin{commentary} + This added step 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. + + Invalid NAPOT encodings were chosen to raise page-fault exceptions rather + than access-fault exceptions, following the convention that invalid PTE + configurations result in page-faults exceptions, while invalid access + types or accesses to invalid physical memory regions trigger page faults. +\end{commentary} |