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

[1] https://lore.kernel.org/linux-riscv/YsRzVoWOdGqSOZ+q@infradead.org/
[2] https://github.com/guoren83/qemu/tree/rv32svpbmt
[3] https://lore.kernel.org/linux-riscv/20220710075644.738455-1-guoren@kernel.org/

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  ========================
\section{Sv32: Page-Based 32-bit Virtual-Memory Systems}
\label{sec:sv32}
...
\subsection{Svnapot and Svpbmt}
\label{sec:translation}

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).

\begin{commentary}
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.
\end{commentary}

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}
\label{svnapot}

-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:

\begin{center}\em
\begin{tabular}{|c|c||l|c|}
@@ -2384,6 +2483,23 @@ algorithm in Section~\ref{sv32algorithm}, except that:
\end{tabular}
\end{center}

+ 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}
\label{svpbmt}

-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}.