Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

Ved Shanbhogue

Couple of questions:

1. Treatment of Sv32x4 when mencvcfg.PBMT is set is not mentioned. Is that intensional? Or is it expected to follow the redefinition?
2. When H-extension is support and the hypervisor intends to uses Sv32 (without the 31-bit restriction) then it it will be unable to run a Sv32 guest with the 31-bit restriction as the menvcfg will apply to both the V=0 and V=1 execution. Was this intentional?
3. If menvcfg.PBMT is set but henvcfg.PBMT is not set is it expected that non-zero
values in bits 30:29 will lead 1) to a page fault OR 2) bits 30:29 being part of
4. If menvcfg.PBMT is set but henvcfg.PBMT is not set what is treatment of N bit. Does it continue to be the N bit, or does bit 31 become part of of PPN[1]?
5. If a hypervisor had a legacy 34-bit VM and hypervisor used say Sv39 and menvcfg.PBMT
was 1. Then the behavior of those 34-bit VMs changes. henvcfg.PBMT does
not help as it was not defined to have effect on Sv32 (see question 3 and 4). How
can the machine support co-existence of existing 32-bit VMs with new 31-bit restricted
6. The Svnapot in the normative text states "The Svnapot extension depends on Sv39". This
statement needs update and qualification.
7. The privilege chapters that discuss the [m|h]envcfg.PBMTE bit need to be updated with
the new behavior now associated with this bit.


On Tue, Jul 19, 2022 at 04:14:06AM -0700, Guo Ren wrote:
The current Privileged specification only defines Svnapot and Svpbmt for RV64 with the highest 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 2GB. Then we have enough highest bits to hold Svnapot & Svpbmt.

We've finished the Linux Proof of concept of the proposal, which contains
three parts:
- Qemu rv32 svpbmt & napot support & hw/virt memory layout of 1GB IO
range [2]
- rv32-Linux kernel Svnapot & Svpbmt support [3]
- Opensbi needs to compile with FW_TEXT_START=0x40000000


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.

Guo Ren


=======================  Supervisor Extension Additions  ========================
\section{Sv32: Page-Based 32-bit Virtual-Memory Systems}
\subsection{Svnapot and Svpbmt}

Sv32 implementations could support Svnapot (Chapter~\ref{svnapot}) and Svpbmt (Chapter~\ref{svpbmt}) with reduced physical address space from 34-bit to 31-bit when {\tt menvcfg}.PBMTE is set. Then the leaved highest three bits are used to support Svnapot and Svpbmt. The 20-bit VPN is translated into a 19-bit physical page number (PPN).

For example, consider an RV32 system supporting 31 bits of physical address with Svnapot and Svpbmt. When the value of {\tt satp}.MODE is Sv32 and {\tt menvcfg}.PBMTE is set, and a 31-bit physical address is produced directly.

Sv32 virtual address:
| 31 22 | 21 12 | 11 0 |
VPN[1] VPN[0] page offset
10 10 12

Sv32 with 31-bit physical address:
| 30 22 | 21 12 | 11 0 |
PPN[1] PPN[0] page offset
9 10 12
Sv32 page table entry with Svnapot and Svpbmt:
| 31 | 30 29 | 28 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
N MT[2] RSV & PFN reserved for SW D A G U X W R V

=======================  Supervisor Extension Mix modification  ===================

diff --git a/src/supervisor.tex b/src/supervisor.tex
@@ -2271,7 +2370,7 @@ equals 8.
\chapter{``Svnapot'' Standard Extension for NAPOT Translation Contiguity, Version 1.0}

-In Sv39, Sv48, and Sv57, when a PTE has N=1, the PTE represents a
+In Sv32, 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
@@ -2364,7 +2463,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
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:
+ arise. For example in Sv39:

@@ -2384,6 +2483,23 @@ algorithm in Section~\ref{sv32algorithm}, except that:

+ For example in Sv32:
+ \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 \\
+ ... & ... & ... & ... \\
+ 1 & {\tt x~xxxx~xxx1} & 8 MiB contiguous region & 1 \\
+ 1 & {\tt x~xxxx~xx10} & 16 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.
@@ -2399,7 +2515,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
\chapter{``Svpbmt'' Standard Extension for Page-Based Memory Types, Version 1.0}

-In Sv39, Sv48, and Sv57, bits 62--61 of a leaf page table entry indicate the use
+In Sv32, bits 31--29 or in Sv39, Sv48, and Sv57 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}.

Join to automatically receive all group messages.