Date
1 - 8 of 8
Fast-track extension proposal V2 for "Sv32 Svpbmt"
|
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 Sv32 physical address with Svpbmt:
| 31 22 | 21 12 | 11 0 | PPN[1] PPN[0] page offset 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}.
|
|
|
|
Greg Favor
Below are my comments ... On Mon, Aug 1, 2022 at 3:34 AM Guo Ren <guoren@...> wrote: First note that a ratified extension will probably appear in the Priv spec as a separate chapter (as was done with the three Sv* extensions ratified last year), or it might be included as part of the Svpbmt chapter as a separate section. Tbd.
The OR is incorrect. For satp only menvcfg matters. For vsatp both menvcfg AND henvcfg matter - as is the case in general for features in VS/VU modes that are controlled by the *envcfg CSRs.
... is ...
This is only true for 4 KiB pages. What about larger page sizes? This probably needs to be expressed in a manner that is page size agnostic.
... of the leaf PTE ...
Satp does not support this translation mode. And satp is not dependent on menvcfg. (Conversely vsatp is dependent on both memvcfg AND henvcfg.) More generally this whole paragraph seems to either have a number of errors or is poorly worded. Also the intro - that says to consider a system supporting the H extension - would seem to focus in on vstap, but then the paragraph starts talking about satp. It probably would be good to have separate paragraphs for the satp functionality and the vsatp functionality (especially since this extension is not limited to use only in virtualized environments).
Isn't this for without Svpbmt?
By merging PPN[1] and PPN[0], this seems to only apply to 4K leaf PTEs? Is that intended or why the merging? Why the '[2]' suffix to 'MT'? PFN doesn't have such a suffix. Conversely the above PPN's have a suffix to distinguish between the two PPN fields. Greg |
|
|
|
Hi Greg,
Thx for the review, here is my reply. On Tue, Aug 2, 2022 at 1:40 AM Greg Favor <gfavor@...> wrote: Agree, I would put it in the Svpbmt chapter as a separate section. My meaning here is satp with V=0 or V=1, but I agree using vsatp is clearer.The Sv32 Svpbmt extension adds Svpbmt (Chapter~\ref{svpbmt}) support to Sv32 For vsatp both menvcfg AND henvcfg matter - as is the case in general for features in VS/VU modes that are controlled by the *envcfg CSRs.vsatp depends on henvcfg.PBMTE, and henvcfg.PBMTE depends on menvcfg.PBMTE. Here is the rewritten sentence: 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 and leaving the highest 2 bits of the leaf PTE as PBMT properties for two-level translation. The satp and hgatp depend on henvcfg.PBMTE, and the vsatp depends on henvcfg.PBMTE. When menvcfg.PBMTE not set, henvcfg.PBMTE must be zero. I think the sentence could be removed. Look at the below commentary part. Yes, I've done. How about: \begin{commentary} For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4 and menvcfg.PBMTE set, 32-bit physical address with PBMT is translated for V=0. When vsatp.mode is Sv32x4 and henvcfg.PBMTE set, 32-bit physical address with PBMT is translated for V=1. \end{commentary} I separate them in latex diff; the style is from the Linux comment. | 31 30 | 29 20 | 19 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 PBMT PFN[1] PFN[0] reserved for SW D A G U X W R V This means 2 bits for PBMT, it's from the Linux comment. I agree with using the spec style here.
-- Best Regards Guo Ren |
|
|
|
Greg Favor
On Mon, Aug 1, 2022 at 7:45 PM Guo Ren <guoren@...> wrote: > For vsatp both menvcfg AND henvcfg matter - as is the case in general for features in VS/VU modes that are controlled by the *envcfg CSRs. The preceding, as worded, could be simplified down to "The satp, hgatp, and vsatp CSRs all depend on henvcfg.PBMTE." But the above sentence is not correct in that satp does not depend on henvcfg.PBMTE. And hgatp also does not depend on henvcfg.PBMTE. It would be better to not try and redundantly repeat what is already specified in the Priv arch spec (and possibly get it wrong). Instead, using the same terminology as used in the description of the PBMTE bits, say that S-mode, G-stage, and VS-stage address translation under this extension are controlled by the menvcfg.PBMTE and henvcfg.PBMTE bits in the same manner as for the SvPbmt extension. How about: Note that you can't use the same name 'Svpmt' for this new extension. Every extension must have a distinct name of its own. and Hypervisor Satp doesn't support this mode. Neither does vsatp. and Note that physical addresses are not "translated"; they are the result of a translation. Virtual addresses are "translated" into physical addresses. for V=0. Note that satp is only used when V=0; vsatp is used when V=1. So the "V=0" qualifier for satp is not only unnecessary but also undesirable in suggesting that the qualifier has some significance of its own. Greg When vsatp.mode is Sv32x4 and henvcfg.PBMTE set, 32-bit physical |
|
|
|
On Tue, Aug 2, 2022 at 2:16 PM Greg Favor <gfavor@...> wrote:
Sorry for the typo, It should be: "The satp and hgatp depend on menvcfg.PBMTE, and the vsatp depends on henvcfg.PBMTE." Good point. I would try; see below. Svpbmt32 is good, I would put it into OkayHow about: Yes, Sv32. It comes from hgatp, Sv32x4 means 34-bit virtual guest physical address, right? Yes, you are right. Okay. Please have a look at below: \subsection{``Svpbmt32'' Extension for Page-Based Memory Types} \label{sec:translation} The Svpbmt32 extension adds Svpbmt (Chapter~\ref{svpbmt}) support to Sv32 implementations by reducing the physical address space from 34-bit to 32-bit to hold the highest 2 PBMT bits. The S-mode and G-stage address translation under this extension are controlled by the menvcfg.PBMTE. The VS-stage address translation under this extension is controlled by the henvcfg.PBMTE. The henvcfg.PBMTE depends on menvcfg.PBMTE. \begin{commentary} For example, consider an RV32 system supporting Svpbmt32 and Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32 and menvcfg.PBMTE set, HS-mode virtual addresses and guest physical addresses are translated to 32-bit physical addresses with PBMT. When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual addresses are translated to 32-bit guest physical address with PBMT. \end{commentary} Sv32 virtual address: | 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 20 | 19 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 PBMT PFN[1] PFN[0] reserved for SW D A G U X W R V -- Best Regards Guo Ren |
|
|
|
Greg Favor
On Tue, Aug 2, 2022 at 4:48 AM Guo Ren <guoren@...> wrote: >> and Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4 Yes. The Svpbmt32 extension adds Svpbmt The more proper way to say this is that PBMT support is being added (versus saying that an existing extension is being added). (Chapter~\ref{svpbmt}) support to Maybe say "... to allow use of the two highest bits instead as PBMT bits." . The S-mode and Maybe say "... controlled by henvcfg.PBMTE and indirectly also menvcfg.PBMTE."
It would be better to describe this in the same way as the existing PBMTE description, i.e. "When menvcfg.PBMTE=1,
Svpbmt32 is available for S-mode and G-stage address translation." Ultimately these statements will need to be incorporated into the two existing PBMTE descriptions (for menvcfg and henvcfg), but in the meantime one should use the same wording as the existing descriptions. When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual Same comment as above. Sv32 physical address with Svpbmt: I assume the preceding should be 'Svpbmt32'. | 31 30 | 29 20 | 19 10 | 9 8 | 7 | 6 | 5 What does 'PFN' stand for? But more importantly why change names from PPN to PFN (versus maintaining the same naming as in the existing spec)? Especially since PFN[0] is the same as PPN[0], and PFN[1] is just a smaller version of PPN[1]. Greg |
|
|
|
On Wed, Aug 3, 2022 at 12:46 AM Greg Favor <gfavor@...> wrote:
Okay. Okay. Okay. Okay, I would try; see below. Okay Okay, I will fix it. \subsection{Svpbmt32} .\label{sec:translation} Svpbmt32 support is being added to allow the two highest bits of PTE used as PBMT for Sv32. The S-mode and G-stage address translation under this extension are controlled by the menvcfg.PBMTE. The VS-stage address translation under this extension is controlled by henvcfg.PBMTE and menvcfg.PBMTE indirectly. \begin{commentary} For example, consider an RV32 system supporting Svpbmt32 and Hypervisor Extension (Chapter~\ref{hypervisor}). When menvcfg.PBMTE=1, Svpbmt32 is available for S-mode and G-stage address translation. When henvcfg.PBMTE=1, Svpbmt32 is available for VS-mode address translation. \end{commentary} Sv32 virtual address: | 31 22 | 21 12 | 11 0 | VPN[1] VPN[0] page offset 10 10 12 Sv32 physical address with Svpbmt32: | 31 22 | 21 12 | 11 0 | PPN[1] PPN[0] page offset 10 10 12 Sv32 page table entry with Svpbmt32: | 31 30 | 29 20 | 19 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 PBMT PPN[1] PPN[0] reserved for SW D A G U X W R V
-- Best Regards Guo Ren |
|
|
|
On Wed, Aug 3, 2022 at 9:10 PM Guo Ren <guoren@...> wrote:
Update above with Allen help, to make the description flow better: Svpbmt32 support is being added to allow the two highest bits of a PTE to be used as PBMT instead of PA[33:32] for Sv32. The S-mode and G-stage address translation under this extension are controlled by the menvcfg.PBMTE. The VS-stage address translation under this extension is controlled by henvcfg.PBMTE and indirectly by menvcfg.PBMTE.
-- Best Regards Guo Ren |
|
|