Svukte v0.3

Changes:

- Extension renamed from Svkt to Svukte
- SVKT field renamed to UKTE
- HUVKT field moved from henvcfg to hstatus
- HUVKT field renamed to HUKTE

src/hypervisor.adoc

@@ -188,6 +188,13 @@ If HSXLEN is changed from 32 to a wider width, and if field VSXL is not
 restricted to a single value, it gets the value corresponding to the
 widest supported width not wider than the new HSXLEN.
 
+If the Svukte extension is implemented, the HUKTE field determines
+whether the HLV, HLVX, and HSV instructions, when executed in U-mode,
+are Svukte-qualified.
+When one of these instructions is executed in U-mode, it behaves as though
+`senvcfg`.UKTE were set to the value of HUKTE.
+If Svukte is not implemented, HUKTE is read-only zero.
+
 The `hstatus` fields VTSR, VTW, and VTVM are defined analogously to the
 `mstatus` fields TSR, TW, and TVM, but affect execution only in VS-mode,
 and cause virtual-instruction exceptions instead of illegal-instruction
@@ -594,9 +601,7 @@ mode V=1.
   {bits:  2, name: 'CBIE'},
   {bits:  1, name: 'CBCFE'},
   {bits:  1, name: 'CBZE'},
-  {bits: 16, name: 'WPRI'},
-  {bits: 1, name: 'HUVKT'},
-  {bits: 7, name: 'WPRI'},
+  {bits: 24, name: 'WPRI'},
   {bits:  2, name: 'PMM'},
   {bits: 25, name: 'WPRI'},
   {bits:  1, name: 'DTE'},
@@ -654,13 +659,6 @@ The definition of the CBZE field is furnished by the Zicboz extension.
 
 The definitions of the CBCFE and CBIE fields are furnished by the Zicbom extension.
 
-If the Svkt extension is implemented, the HUVKT field determines
-whether the HLV, HLVX, and HSV instructions, when executed in U-mode,
-are Svkt-qualified.
-When one of these instructions is executed in U-mode, it behaves as though
-`senvcfg`.SVKT were set to the value of HUVKT.
-If Svkt is not implemented, HUVKT is read-only zero.
-
 The definition of the PMM field will be furnished by the forthcoming
 Ssnpm extension. Its allocation within `henvcfg` may change prior to the
 ratification of that extension.

src/images/bytefield/hstatusreg.edn

@@ -7,37 +7,43 @@
 (def right-margin 30)
 (def boxes-per-row 32)
 
-(draw-box nil {:span 3 :borders {}})
+(draw-box nil {:span 1 :borders {}})
 (draw-box "63" {:span 8 :borders {} :text-anchor "start"})
 (draw-box "34" {:borders {}})
 (draw-box "33" {:span 2 :borders {} :text-anchor "start"})
 (draw-box "32" {:span 2 :borders {} :text-anchor "end"})
 (draw-box "31" {:span 3 :borders {} :text-anchor "start"})
-(draw-box "23" {:span 3 :borders {} :text-anchor "end"})
+(draw-box "25" {:span 3 :borders {} :text-anchor "end"})
+(draw-box "24" {:span 2:borders {}})
+(draw-box "23" {:span 2:borders {}})
 (draw-box "22" {:span 2:borders {}})
 (draw-box "21" {:span 2 :borders {}})
 (draw-box "20" {:span 2:borders {}})
 (draw-box nil {:borders {}})
-(draw-box nil {:span 3 :borders {}})
+(draw-box nil {:span 1 :borders {}})
 
-(draw-box nil {:span 3 :borders {}})
+(draw-box nil {:span 1 :borders {}})
 (draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 9})
 (draw-box "VSXL[1:0]" {:span 4})
 (draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 6})
+(draw-box "HUVKT" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
 (draw-box "VTSR" {:span 2})
 (draw-box "VTW" {:span 2})
 (draw-box "VTVM" {:span 2})
 (draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
-(draw-box nil {:span 3 :borders {}})
+(draw-box nil {:span 1 :borders {}})
 
-(draw-box nil {:span 3 :borders {}})
+(draw-box nil {:span 1 :borders {}})
 (draw-box "30" {:span 9 :borders {}})
 (draw-box "2" {:span 4 :borders {}})
-(draw-box "9" {:span 6 :borders {}})
+(draw-box "7" {:span 6 :borders {}})
 (draw-box "1" {:span 2 :borders {}})
 (draw-box "1" {:span 2 :borders {}})
 (draw-box "1" {:span 2 :borders {}})
-(draw-box nil {:span 4 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box nil {:span 2 :borders {}})
 
 (draw-box nil {:span 32 :borders {}})
 
@@ -83,4 +89,4 @@
 (draw-box "5" {:span 4 :borders {}})
 (draw-box nil {:span 4 :borders {}})
 
-----
+----

src/supervisor.adoc

@@ -730,7 +730,7 @@ characteristics of the U-mode execution environment.
   {bits:  2, name: 'CBIE'},
   {bits:  1, name: 'CBCFE'},
   {bits:  1, name: 'CBZE'},
-  {bits:  1, name: 'SVKT'},
+  {bits:  1, name: 'UKTE'},
   {bits: 24, name: 'WPRI'},
   {bits:  2, name: 'PMM'},
   {bits: 30, name: 'WPRI'},
@@ -825,13 +825,13 @@ The definitions of the CBCFE and CBIE fields will be furnished by the
 forthcoming Zicbom extension. Their allocations within `senvcfg` may
 change prior to the ratification of that extension.
 
-If the Svkt extension is implemented, the SVKT field affects the behavior of
+If the Svukte extension is implemented, the UKTE field affects the behavior of
 instruction fetches and explicit memory accesses.
-When SVKT=0, instruction fetches and explicit memory accesses proceed as
-though the Svkt extension were not implemented.
-When SVKT=1, instruction fetches and explicit memory accesses with effective
-privilege mode U or VU are Svkt-qualified, as described in <<sec:svkt>>.
-If Svkt is not implemented, SVKT is read-only zero.
+When UKTE=0, instruction fetches and explicit memory accesses proceed as
+though the Svukte extension were not implemented.
+When UKTE=1, instruction fetches and explicit memory accesses with effective
+privilege mode U or VU are Svukte-qualified, as described in <<sec:svukte>>.
+If Svukte is not implemented, UKTE is read-only zero.
 
 The definition of the PMM field will be furnished by the forthcoming
 Ssnpm extension. Its allocation within `senvcfg` may change prior to the
@@ -2279,44 +2279,44 @@ Invalid PTEs using a bounded timer, or making address-translation caches
 coherent with store instructions that modify PTEs.
 ====
 
-[[sec:svkt]]
-== "Svkt" Extension for Address-Independent Latency of User-Mode Faults to Supervisor Addresses, Version 0.2
+[[sec:svukte]]
+== "Svukte" Extension for Address-Independent Latency of User-Mode Faults to Supervisor Addresses, Version 0.3
 
-The Svkt extension provides a means to make user-mode accesses to supervisor
+The Svukte extension provides a means to make user-mode accesses to supervisor
 memory raise page faults in constant time, mitigating attacks that attempt to
 discover the supervisor software's address-space layout.
 
-If the Svkt extension is implemented, the `senvcfg`.SVKT field is writable.
-If the hypervisor extension is additionally implemented, the `henvcfg`.HUVKT
+If the Svukte extension is implemented, the `senvcfg`.UKTE field is writable.
+If the hypervisor extension is additionally implemented, the `hstatus`.HUKTE
 field is also writable.
-See <<sec:senvcfg>> and <<sec:henvcfg>> for the definitions of those fields.
+See <<sec:senvcfg>> and <<sec:hstatus>> for the definitions of those fields.
 
-The Svkt extension depends on Sv39.
+The Svukte extension depends on Sv39.
 
-NOTE: Svkt is not defined for Sv32 because the small address space limits the
+NOTE: Svukte is not defined for Sv32 because the small address space limits the
 available entropy, reducing the effectiveness of address-space layout
 randomization.
 If an Sv32 variant were to be defined, it would need to account for the fact
 that it is more common to reserve only the upper 1 GiB of the virtual-address
 space for the operating system, leaving the lower 3 GiB for user
 processes.
 
-When `senvcfg`.SVKT=1, an instruction fetch or explicit memory access whose
-effective privilege mode is U or VU is considered to be _Svkt-qualified_.
-For any Svkt-qualified memory access, virtual addresses {ge} 2^SXLEN-1^ are
-considered to be invalid; hence, an Svkt-qualified access to such an address
+When `senvcfg`.UKTE=1, an instruction fetch or explicit memory access whose
+effective privilege mode is U or VU is considered to be _Svukte-qualified_.
+For any Svukte-qualified memory access, virtual addresses {ge} 2^SXLEN-1^ are
+considered to be invalid; hence, an Svukte-qualified access to such an address
 raises a page-fault exception corresponding to the original access type.
 The timing of an instruction that raises an exception for this reason must be
 independent of the faulting virtual address.
 
-NOTE: Since whether an instruction is Svkt-qualified depends on the _effective_
+NOTE: Since whether an instruction is Svukte-qualified depends on the _effective_
 privilege mode of the access, even some instructions executed in HS-mode or M-mode
 (e.g. HLV with `hstatus`.SPVP=0, or LW with `mstatus`.MPRV=1 and
-`mstatus`.MPP=U) are Svkt-qualified.
+`mstatus`.MPP=U) are Svukte-qualified.
 
-As described in <<sec:henvcfg>>, the `henvcfg`.HUVKT field, rather than the
-`senvcfg`.SVKT field, determines whether HLV, HLVX, and HSV instructions
-executed within U-mode are Svkt-qualified.
+As described in <<sec:hstatus>>, the `hstatus`.HUKTE field, rather than the
+`senvcfg`.UKTE field, determines whether HLV, HLVX, and HSV instructions
+executed within U-mode are Svukte-qualified.
 
 ////
 [[sec:ssqosid]]