Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add disjoint addressing mode draft proposal #128

wants to merge 2 commits into
base: master
Changes from all commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.
+212 −0
Diff settings


Just for now

@@ -218,6 +218,7 @@ \section{CSR Listing}
\multicolumn{4}{|c|}{Supervisor Protection and Translation} \\
\tt 0x180 & SRW &\tt satp & Supervisor address translation and protection. \\
\tt 0x181 & SRW &\tt suatp & Supervisor-controlled user address translation and protection. \\
@@ -74,6 +74,8 @@


@@ -0,0 +1,209 @@
\chapter{``Sdas'' Standard Extension for Disjoint User/Supervisor
Address Spaces, Version 0.1}

This chapter describes the Sdas standard extension for disjoint user and
supervisor address spaces. Two operating modes are defined: {\em unified
addressing mode} is the traditional model, where the supervisor is mapped
into the user address space and isolated only by page permissions, and {\em
disjoint addressing mode}, where the user and supervisor address spaces
use independent page tables.

All CSRs defined in this extension must be implemented if this extension is

\section{Supervisor CSRs}

This extension adds one CSR to the supervisor CSR set, modifies the
interpretation of {\tt satp}, and adds two bits to {\tt sstatus}.

\subsection{Supervisor Address Translation and Protection ({\tt satp}) Register}

The {\tt satp} CSR controls address translation in S-mode and retains its
format from the baseline supervisor support.

For backwards compatibility, writes to {\tt satp} also write the same value
to {\tt suatp}. The CSR read-modify-write instructions may either read the
value from {\tt satp}, modify it and write it to both {\tt satp} and {\tt
suatp} or independently modify both {\tt satp} and {\tt suatp}.
Supervisors that use disjoint addressing mode must ensure that {\tt suatp}
is reloaded with a known value after performing a read-modify-write on {\tt
satp}. Supervisors that use unified addressing mode will observe no
difference, since {\tt satp} and {\tt suatp} will at all times contain the
same value if only {\tt satp} is written.

\subsection{Supervisor-controlled User Address Translation and Protection
({\tt suatp}) Register}

The {\tt suatp} CSR controls address translation in U-mode and shares the
same format as the {\tt satp} CSR. The MODE field in {\tt suatp} must be
written with the same value as the MODE field in {\tt satp} by supervisors
using disjoint addressing mode; values different from MODE in {\tt satp}
are reserved for future extensions that permit user and supervisor address
spaces to use different paging depths. Supervisors that use unified
addressing mode will implicitly set the MODE fields in both {\tt suatp} and
{\tt satp} to the same value when they write to the {\tt satp} CSR.

If the MODE field in {\tt suatp} contains an illegal value, all user
translations will fault. Implementations must permit the MODE fields in
{\tt satp} and {\tt suatp} to contain the same value. Future extension may
standardize other permitted values.

The choice of retaining CSR 0x180 as {\tt satp} was driven by concerns for
backwards compatibility and hardware simplicity. This choice permits
hardware to always operate in disjoint addressing mode, while unified
addressing mode is provided by also writing {\tt suatp} when {\tt satp} is
written. A supervisor using disjoint addressing mode will write {\tt satp}
once and then write {\tt suatp} on every task switch. A supervisor that
does not support disjoint addressing mode will write {\tt satp} on every
task switch.

\subsection{Supervisor Status ({\tt sstatus}) Register}

Two one-bit fields are added to {\tt sstatus} (and therefore also to {\tt
mstatus} and any other CSRs that contain {\tt sstatus}) to provide S-mode
software with easy access to disjoint user address spaces.

\instbit{} &
\instbit{24} &
\instbit{23} &
\instbit{} \\
\multicolumn{1}{c|}{$\cdots$} &
\multicolumn{1}{c|}{{\tt SSU}} &
\multicolumn{1}{c|}{{\tt SLU}} &
\multicolumn{1}{c}{$\cdots$} \\
& 1 & 1 & \\
\caption{Additional Fields in {\tt sstatus}}

Implementations supporting disjoint addressing mode must implement SLU and
SSU. Implementations not supporting disjoint addressing mode must hardwire
these bits to zero, as the fields are \wpri\ otherwise.

The SSU and SLU bits affect instructions using a specific major opcode:
\item SLU (Supervisor Load from User memory) affects LOAD instructions
\item SSU (Supervisor Store to User memory) affects STORE instructions

The SLU bit also affects LQ on RV128, even though LQ is encoded using the
MISC-MEM major opcode because LOAD is full.

The SSU and SLU bits are ignored if SPP is S.

This ensures that a horizontal trap within the supervisor will be correctly
handled without requiring context-save areas to be aliased in the user
address space.

\section {Supervisor Instructions}

\subsection{Supervisor Memory-Management Fence Instruction}

The SFENCE.VMA instruction defined in Section~\ref{sec:sfence.vma} is
modified when this extension is implemented.

When {\em rs2}$\neq${\tt x0}, bits XLEN-1:ASIDMAX+1 of the value held in
{\em rs2} are reserved for future use and should be zeroed by software and
ignored by current implementations. Bit ASIDMAX is used to select the
supervisor address space if disjoint addressing mode is in use. If
disjoint addressing mode is in use ({\tt satp}$\neq${\tt suatp}), the fence
applies to the supervisor address space if bit ASIDMAX is set and to the
user address space if bit ASIDMAX is clear. If unified addressing mode is
in use ({\tt satp}={\tt suatp}), the fence is applied to both address
spaces independently and bit ASIDMAX is ignored.

\section{Implementation Requirements}

Implementations supporting disjoint addressing mode must bifurcate ASID
space into disjoint user and supervisor sections. User and supervisor
ASIDs are unrelated and independent for all implemented ASID numbers.

Each user ASID must appear to have an independent MMU and
microarchitectural address translation resources must be partitioned
between user ASIDs such that activity in or presence of one user ASID has
no effect whatsoever on activity in other user ASIDs, excepting memory bus
contention and other effects also observable with fully-independent

Supervisor ASIDs are not required to have similar isolation, since
supervisors that use disjoint addressing mode will probably use only one or
a few ASIDs and the other supervisor ASID resources should remain
available. A supervisor using unified addressing mode will effectively
replicate its mappings across all supervisor ASIDs.

Each user ASID must be isolated from all supervisor ASIDs, just as each
user ASID must be isolated from all other user ASIDs.

The virtualization extension uses second-level translation with guest
accesses translated as user accesses in the hypervisor; these second-level
translations are considered to occur in a user ASID and therefore guest
virtual machines benefit from the user ASID isolation guarantees.

These requirements are intended to forbid side channels between user
processes or guest virtual machines that would otherwise leak information.
Fully closing all side channels in the memory subsystem would be extremely
expensive, which is the rationale for permitting interactions that can
occur in a system with fully-independent processors.

The {\em scope} of an ASID is defined as the set of harts where loading an
\{ASID, PPN\} tuple into an address translation and protection CSR can
conflict with cached translations associated with an \{ASID, PPN'\} tuple.
The narrowest possible ASID scope is {\em hart-local}: two harts may have
different root pages for the same ASID without conflict. The widest
possible scope is {\em global}: ASID numbers must be unique within the

User ASIDs have implementation-defined scope and may have global scope
provided that the implementation provides at least as many ASIDs as S-mode
harts. Otherwise, user ASIDs must have narrower scope either limited to
some group of harts or be local to a single hart.

Supervisor ASIDs are always hart-local. Supervisors are explicitly
permitted to reduce remapping overhead by using per-hart root page tables
with a single ASID.

Supervisors can use both the SSU and SLU fields and virtual memory aliasing
to access user memory. The requirement that supervisor ASIDs be local to a
hart allows a supervisor to use per-hart root page tables and avoid
synchronization overhead when configuring alias mappings for access to user
address spaces.

\section{Effect of Disjoint Address Spaces on Page Translations}

The PTE U bit is honored in both address spaces, even though the supervisor
address space is entirely inaccessible to user mode. This allows
supervisors that maintain direct-mapped windows into physical memory to
mark pages allocated to user space as user pages, permitting inadvertent
accesses to be caught using SUM without making those mappings visible to
user programs.

All user translations are performed using the page tables from {\tt suatp}.
Except when modified by the SSU and SLU flags in {\tt sstatus}, all
supervisor translations are performed from the page tables from {\tt satp}.
The rule that a write to CSR 0x180 writes both {\tt satp} and {\tt suatp}
preserves backwards compatibility.
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.