Excised H-mode from spec.

1 files changed, 32 insertions, 25 deletions

diff --git a/src/priv-intro.tex b/src/priv-intro.tex
index ebed27c..92cb855 100644
--- a/src/priv-intro.tex
+++ b/src/priv-intro.tex
@@ -23,7 +23,7 @@ possibly without even changing the ABI.  In particular, this
 privileged specification was designed to run existing popular
 operating systems, and so embodies the conventional level-based
 protection model.  Alternate privileged specifications could embody
-other more flexible protection domain models.
+other more flexible protection-domain models.
 \end{commentary}
 
 \section{RISC-V Hardware Platform Terminology}
@@ -143,7 +143,7 @@ execution environments (AEE, SEE, or HEE).
 
 At any time, a RISC-V hardware thread ({\em hart}) is running at some
 privilege level encoded as a mode in one or more CSRs (control and
-status registers).  Four RISC-V privilege levels are currently defined
+status registers).  Three RISC-V privilege levels are currently defined
 as shown in Table~\ref{privlevels}.
 
 \begin{table*}[h!]
@@ -153,7 +153,7 @@ as shown in Table~\ref{privlevels}.
    Level & Encoding & Name      & Abbreviation \\ \hline  
    0     & \tt 00   & User/Application & U     \\ 
    1     & \tt 01   & Supervisor & S           \\ 
-   2     & \tt 10   & Hypervisor & H           \\ 
+   2     & \tt 10   & {\em Reserved} &            \\ 
    3     & \tt 11   & Machine    & M           \\ 
   \hline
  \end{tabular}
@@ -166,31 +166,35 @@ Privilege levels are used to provide protection between different
 components of the software stack, and attempts to perform operations
 not permitted by the current privilege mode will cause an exception to
 be raised.  These exceptions will normally cause traps into an
-underlying execution environment or the HAL.
+underlying execution environment.
 
 The machine level has the highest privileges and is the only mandatory
 privilege level for a RISC-V hardware platform.  Code run in
-machine-mode (M-mode) is inherently trusted, as it has low-level
-access to the machine implementation.  M-mode is used to manage secure
-execution environments on RISC-V.  User-mode (U-mode) and
-supervisor-mode (S-mode) are intended for conventional application and
-operating system usage respectively, while hypervisor-mode (H-mode) is
-intended to support virtual machine monitors.
+machine-mode (M-mode) is usually inherently trusted, as it has
+low-level access to the machine implementation.  M-mode can be used to
+manage secure execution environments on RISC-V.  User-mode (U-mode)
+and supervisor-mode (S-mode) are intended for conventional application
+and operating system usage respectively.
+
+\begin{commentary}
+The previous Hypervisor mode (H-mode) designed to support Type-1
+hypervisors has been removed and the encoding space reserved as we are
+focusing on hypervisor support via an extended S mode suitable for
+both Type-1 and Type-2 hypervisors as described in
+Chapter~\ref{hypervisor}.  The encoding space for H is reserved for
+future use and to avoid backwards incompatible changes in bit
+positions in various status regusters.  The bit positions might be
+reused in the future for different Type-1 hypervisor support or
+possibly additional secure execution modes.
+\end{commentary}
 
 Each privilege level has a core set of privileged ISA extensions with
 optional extensions and variants.  For example, machine-mode supports
 several optional standard variants for address translation and memory
-protection.
-
-\begin{commentary}
-Although none are currently defined, future hypervisor-level ISA
-extensions will be added to improve virtualization performance.  One
-common feature to support hypervisors is to provide a second level of
-translation and protection, from {\em supervisor physical addresses}
-to {\em hypervisor physical addresses}.
-\end{commentary}
+protection.  Also, supervisor-mode can be extended to support Type-2
+hypervisor execution as described in Chapter~\ref{hypervisor}.
 
-Implementations might provide anywhere from 1 to 4 privilege modes
+Implementations might provide anywhere from 1 to 3 privilege modes
 trading off reduced isolation for lower implementation cost, as shown
 in Table~\ref{privcombs}.
 
@@ -215,8 +219,7 @@ trapped and emulated by the SEE running in the higher-privilege level.
    Number of levels &  Supported Modes & Intended Usage \\ \hline  
    1     & M          & Simple embedded systems \\ 
    2     & M, U       & Secure embedded systems \\ 
-   3     & M, S, U    & Systems running Unix-like operating systems \\ 
-   4     & M, H, S, U & Systems running Type-1 hypervisors \\ 
+   3     & M, S, U    & Systems running Unix-like operating systems\\ 
   \hline
  \end{tabular}
 \end{center}
@@ -228,12 +231,16 @@ All hardware implementations must provide M-mode, as this is the only
 mode that has unfettered access to the whole machine.  The simplest
 RISC-V implementations may provide only M-mode, though this will
 provide no protection against incorrect or malicious application code.
+
+\begin{commentary}
+  The lock feature of the optional PMP facility can provide some
+  limited protection even with only M-mode implemented.
+\end{commentary}
+
 Many RISC-V implementations will also support at least user mode
 (U-mode) to protect the rest of the system from application code.
 Supervisor mode (S-mode) can be added to provide isolation between a
-supervisor-level operating system and the SEE and HAL code.  The
-hypervisor mode (H-mode) is intended to provide isolation between a
-virtual machine monitor and a HEE and HAL running in machine mode.
+supervisor-level operating system and the SEE.
 
 A hart normally runs application code in U-mode until some trap (e.g.,
 a supervisor call or a timer interrupt) forces a switch to a trap