From 395134ec130aaece03991e1109af2e09999a091a Mon Sep 17 00:00:00 2001 From: Daniel Lustig Date: Sun, 22 Aug 2021 13:05:16 -0400 Subject: Some cosmetic reformatting Thanks to suggestions from @jscheid-ventana --- src/supervisor.tex | 50 +++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/src/supervisor.tex b/src/supervisor.tex index e426beb..545edfd 100644 --- a/src/supervisor.tex +++ b/src/supervisor.tex @@ -2121,7 +2121,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 @@ -2140,44 +2140,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} @@ -2200,9 +2200,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 -- cgit v1.1 From 58db9b93f763b00e516e21ad408da09b12f40edb Mon Sep 17 00:00:00 2001 From: Daniel Lustig Date: Sun, 22 Aug 2021 13:30:56 -0400 Subject: Some cosmetic tweaks Thanks to @jscheid-ventana for the suggestions --- src/supervisor.tex | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/src/supervisor.tex b/src/supervisor.tex index 3ceaa9e..222f802 100644 --- a/src/supervisor.tex +++ b/src/supervisor.tex @@ -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 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 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, 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 -- cgit v1.1