Made clear this document written as if only privileged architecture.

Minor clarifications.

1 files changed, 15 insertions, 13 deletions

diff --git a/src/priv-intro.tex b/src/priv-intro.tex
index 7787f69..f909ea6 100644
--- a/src/priv-intro.tex
+++ b/src/priv-intro.tex
@@ -19,7 +19,9 @@ 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.  For simplicity of
+expression, the text is written as if this was the only possible
+privileged architecture.
 \end{commentary}
 
 \section{RISC-V Privileged Software Stack Terminology}
@@ -121,17 +123,17 @@ be raised.  These exceptions will normally cause traps into an
 underlying execution environment.
 
 \begin{commentary}
-In the description, we try to separate the {\em privilege level} for
-which code is written, from the {\em privilege mode} in which it runs,
-although the two are often tied.  For example, a supervisor-level
-operating system can run in supervisor-mode on a system with three
-privilege modes, but can also run in user-mode under a classic virtual
-machine monitor on systems with two or more privilege modes.  In both
-cases, the same supervisor-level operating system binary code can be
-used, coded to a supervisor-level SBI and hence expecting to be able
-to use supervisor-level privileged instructions and CSRs.  When
-running a guest OS in user mode, all supervisor-level actions will be
-trapped and emulated by the SEE running in the higher-privilege level.
+In the description, we try to separate the privilege level for which
+code is written, from the privilege mode in which it runs, although
+the two are often tied.  For example, a supervisor-level operating
+system can run in supervisor-mode on a system with three privilege
+modes, but can also run in user-mode under a classic virtual machine
+monitor on systems with two or more privilege modes.  In both cases,
+the same supervisor-level operating system binary code can be used,
+coded to a supervisor-level SBI and hence expecting to be able to use
+supervisor-level privileged instructions and CSRs.  When running a
+guest OS in user mode, all supervisor-level actions will be trapped
+and emulated by the SEE running in the higher-privilege level.
 \end{commentary}
 
 The machine level has the highest privileges and is the only mandatory
@@ -205,4 +207,4 @@ considered an additional privilege mode, with even more access than
 M-mode. The separate debug specification proposal describes operation
 of a RISC-V hart in debug mode.  Debug mode reserves a few CSR
 addresses that are only accessible in D-mode, and may also reserve
-some portions of the physical memory space on a platform.
+some portions of the physical address space on a platform.