tie hardware enabling to Svade/Svadu

Author: tariqkurd-repo

src/cheri-pte-ext.adoc

@@ -100,7 +100,7 @@ If the CW bit is clear then:
 * When CRG is clear, the "no capability state", a store page fault exception
  is raised when a capability store or AMO instruction is executed and the tag bit
  of the capability being written is set.
-* When CRG is set, the "pre-CW state", two schemes are permitted:
+* When CRG is set, the "pre-CW state", two schemes are permitted (also see <<section_hardware_pte_updates>>):
 
 ** The same behavior as when CRG is clear, allowing software interpretation
 of this state.
@@ -160,10 +160,16 @@ bit value of the capability read. This will introduce additional traps during re
  It is legal for the implementation to fault even if the tag is not set since this behaviour is only an optimization for software.
  This means it is also legal to only check the tag under certain conditions and conservatively fault otherwise.
 
-^2^ The choice here follows the pattern of whether to implement the _Svade_ extension
- to take page-fault exceptions for A and D PTE bit state changes, or whether to implement
- a hardware updating mechanism. Software should implement support for a page fault in these cases
- which will not be used if the hardware mechanism is implemented.
+^2^ See <<section_hardware_pte_updates>>.
+
+[#section_hardware_pte_updates]
+=== Enabling Software or Hardware PTE updates
+
+The decision about whether to take exceptions on capability stores with the tag set to a page with PTE.CW=0 and PTE.CRG=1 is determined by whether the _Svade_ and _Svadu_ extensions are enabled.
+These cause PTE Accessed and Dirty updates to be done in software, via the exception handler, or by a hardware mechanism respectively.
+
+* If only _Svade_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then take a page fault.
+* If only _Svadu_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then do the hardware update of setting PTE.CW=1 and setting PTE.CRG=<<sstatusreg_pte,sstatus>>.CRG as described in <<section_extending_pte>>.
 
 [#xstatus_pte]
 === Extending the Supervisor (sstatus) and Virtual Supervisor (vsstatus) Status Registers