Hi,
Here is the second version of the proposal.
The current Privileged specification only defines Svpbmt for RV64 with the 62-61 bits in PTE, and there are no spare highest bits in rv32 for 34-bit physical addressing. But "the lack of rv32 in svpbmt was a very odd choice [1]" mentioned by Christoph Hellwig (Linux DMA MAPPING HELPERS Maintainer), that's very true in practice requirements, and it also blocks the development of rv32-Linux cost-down chip production.
Rv32-Linux currently only supports 1GB of DRAM for maximum, and there is no plan for high-memory. So, there seems to be no obstacle to shrinking the physical address space of the rv32 from 16GB to 4GB. Then we have 31-30 bits to hold Svpbmt.
The draft spec below provides all the details. Note that this extension very specifically strives to maintain maximal consistency with many little details in the existing Privileged architecture.
This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.
Thanks,
Guo Ren
========================================================================
======================= Supervisor Extension Additions ========================
\subsection{Sv32 Svpbmt}
\label{sec:translation}
The Sv32 Svpbmt extension adds Svpbmt (Chapter~\ref{svpbmt}) support to Sv32
implementations by reducing the physical address space from 34-bit to 32-bit,
when {\tt menvcfg}.PBMTE (for V=0) or {\tt henvcfg}.PBMTE (for V=1) set. Then
the 20-bit VPN is translated into a 20-bit physical page number (PPN), and
the highest 2 bits are PBMT properties.
\begin{commentary}
For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension
(Chapter~\ref{hypervisor}). When the value of {\tt vsatp}.MODE is Sv32x4 and
the {\tt henvcfg}.PBMTE set, a 32-bit physical address is produced with PBMT
attribute when in VS-mode and VU-mode. When the value of {\tt satp}.MODE is
Sv32x4 and the {\tt menvcfg}.PBMTE set, a 32-bit physical address is produced
with PBMT attribute from 32-bit ({\tt henvcfg}.PBMTE = 1) or 34-bit
({\tt henvcfg}.PBMTE = 0) guest physical address.
\end{commentary}
Sv32 virtual address with Svpbmt:
| 31 22 | 21 12 | 11 0 |
VPN[1] VPN[0] page offset
10 10 12
Sv32 physical address with Svpbmt:
| 31 22 | 21 12 | 11 0 |
PPN[1] PPN[0] page offset
10 10 12
Sv32 page table entry with Svpbmt:
| 31 30 | 29 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
MT[2] PFN reserved for SW D A G U X W R V
========================================================================
================================ Latex diff ===============================
diff --git a/src/supervisor.tex b/src/supervisor.tex
index 30e52264328b..eac8e8b7210a 100644
--- a/src/supervisor.tex
+++ b/src/supervisor.tex
@@ -1657,6 +1657,106 @@ For implementations with both page-based virtual memory and the ``A'' standard
extension, the LR/SC reservation set must lie completely within a single
base page (i.e., a naturally aligned \wunits{4}{KiB} region).
+\subsection{Sv32 Svpbmt}
+\label{sec:translation}
+
+The Sv32 Svpbmt extension adds Svpbmt (Chapter~\ref{svpbmt}) support to Sv32
+implementations by reducing the physical address space from 34-bit to 32-bit,
+when {\tt menvcfg}.PBMTE (for V=0) or {\tt henvcfg}.PBMTE (for V=1) set. Then
+the 20-bit VPN is translated into a 20-bit physical page number (PPN), and
+the highest 2 bits are PBMT properties.
+
+\begin{commentary}
+For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension
+(Chapter~\ref{hypervisor}). When the value of {\tt vsatp}.MODE is Sv32x4 and
+the {\tt henvcfg}.PBMTE set, a 32-bit physical address is produced with PBMT
+attribute when in VS-mode and VU-mode. When the value of {\tt satp}.MODE is
+Sv32x4 and the {\tt menvcfg}.PBMTE set, a 32-bit physical address is produced
+with PBMT attribute from 32-bit ({\tt henvcfg}.PBMTE = 1) or 34-bit
+({\tt henvcfg}.PBMTE = 0) guest physical address.
+\end{commentary}
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{@{}O@{}O@{}E}
+\instbitrange{31}{22} &
+\instbitrange{21}{12} &
+\instbitrange{11}{0} \\
+\hline
+\multicolumn{1}{|c|}{VPN[1]} &
+\multicolumn{1}{c|}{VPN[0]} &
+\multicolumn{1}{c|}{page offset} \\
+\hline
+10 & 10 & 12 \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Sv32 virtual address with Svpbmt.}
+\label{sv32va}
+\end{figure*}
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{@{}E@{}O@{}E}
+\instbitrange{31}{22} &
+\instbitrange{21}{12} &
+\instbitrange{11}{0} \\
+\hline
+\multicolumn{1}{|c|}{PPN[1]} &
+\multicolumn{1}{c|}{PPN[0]} &
+\multicolumn{1}{c|}{page offset} \\
+\hline
+10 & 10 & 12 \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Sv32 physical address with Svpbmt.}
+\label{rv32va}
+\end{figure*}
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{F@{}O@{}O@{}Fcccccccc}
+\instbitrange{31}{30} &
+\instbitrange{29}{20} &
+\instbitrange{19}{10} &
+\instbitrange{9}{8} &
+\instbit{7} &
+\instbit{6} &
+\instbit{5} &
+\instbit{4} &
+\instbit{3} &
+\instbit{2} &
+\instbit{1} &
+\instbit{0} \\
+\hline
+\multicolumn{1}{|c|}{PBMT} &
+\multicolumn{1}{|c|}{PPN[1]} &
+\multicolumn{1}{c|}{PPN[0]} &
+\multicolumn{1}{c|}{RSW} &
+\multicolumn{1}{c|}{D} &
+\multicolumn{1}{c|}{A} &
+\multicolumn{1}{c|}{G} &
+\multicolumn{1}{c|}{U} &
+\multicolumn{1}{c|}{X} &
+\multicolumn{1}{c|}{W} &
+\multicolumn{1}{c|}{R} &
+\multicolumn{1}{c|}{V} \\
+\hline
+2 & 10 & 10 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Sv32 page table entry with Svpbmt.}
+\label{sv32pte}
+\end{figure*}
+
\subsection{Virtual Address Translation Process}
\label{sv32algorithm}
@@ -2399,7 +2499,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
\chapter{``Svpbmt'' Standard Extension for Page-Based Memory Types, Version 1.0}
\label{svpbmt}
-In Sv39, Sv48, and Sv57, bits 62--61 of a leaf page table entry indicate the use
+In Sv39, Sv48, and Sv57, bits 62--61 (In Sv32 bits 31--30) of a leaf page table entry indicate the use
of page-based memory types that override the PMA(s) for the associated memory
pages. The encoding for the PBMT bits is captured in Table~\ref{pbmt}.
