Minor changes from read-through (#511)

These fixes are based on discussing the current spec with
@LawrenceEsswood.

Minor clarifications no real changes.

---------

Signed-off-by: Tariq Kurd <[email protected]>
Co-authored-by: Lawrence Esswood <[email protected]>
Co-authored-by: Tariq Kurd <[email protected]>

src/debug-integration.adoc

@@ -117,10 +117,9 @@ to this specification. The <<pcc>> metadata has no architectural effect in debug
 mode. Therefore <<asr_perm>> is implicitly granted for access to all CSRs and
 no CHERI instruction fetch faults are possible.
 
-<<dpcc>> (and consequently <<dpc>>) are updated with the
+On debug mode entry <<dpcc>> (and consequently <<dpc>>) are updated with the
 capability in <<pcc>> whose address field is set to the address of the next
-instruction to be executed as described in cite:[riscv-debug-spec] upon
-debug mode entry.
+instruction to be executed upon debug mode exit as described in cite:[riscv-debug-spec].
 
 When leaving debug mode, the capability in <<dpcc>> is unsealed and written
 into <<pcc>>.  A debugger may write <<dpcc>> to change where the hart resumes

src/hypervisor-integration.adoc

@@ -131,7 +131,7 @@ The <<vsepcc>> register is a renamed extension of <<vsepc>> that is able to
 hold a capability. Its reset value is the <<infinite-cap>> capability.
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<vsepcc>> is an executable
-vector, so it need not be able to hold all possible invalid addresses.
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 Additionally, the capability in <<vsepcc>> is unsealed when it is installed in
 <<pcc>> on execute of an <<SRET>> instruction. The handling of <<vsepcc>> is
 otherwise identical to <<mepcc>>, but in virtual supervisor mode.

src/riscv-hybrid-integration.adoc

@@ -317,7 +317,7 @@ the capability stored in <<dddc>>. A debugger may write <<dddc>> to change the
 hart's context.
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<dddc>> is a data pointer,
-so it does not need to be able to hold all possible invalid addresses.
+so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 
 [#section_cheri_disable]
 === Disabling CHERI Registers and Instructions
@@ -353,12 +353,14 @@ CHERI register access is disabled if
 
 The effective CRE for the current privilege is:
 
-* Machine: `mseccfg.CRE`
-* Supervisor: `mseccfg.CRE & menvcfg.CRE`
-* User: `mseccfg.CRE & menvcfg.CRE & senvcfg.CRE`
+* Machine: `<<mseccfg>>.CRE`
+* Supervisor: `<<mseccfg>>.CRE & <<menvcfg>>.CRE`
+* User: `<<mseccfg>>.CRE & <<menvcfg>>.CRE & <<senvcfg>>.CRE`
 
 NOTE: The effective CRE is always 1 in debug mode.
 
+NOTE: On reset CHERI register access is disabled (<<mseccfg>>.CRE resets to zero).
+
 Disabling CHERI register access has no effect on implicit accesses or security
 checks.  The last capability installed in <<pcc>> and <<ddc>> before disabling
 CHERI register access will be used to authorize instruction execution and data
@@ -370,9 +372,10 @@ Disabling CHERI register access prevents low-privileged {cheri_int_mode_name} so
 from interfering with the correct operation of higher-privileged {cheri_int_mode_name} software
 that do not perform <<ddc>> switches on trap entry and return.
 
-Disable CHERI register access also allows harts supporting CHERI to be fully
+Disabling CHERI register access allows harts supporting CHERI to be fully
 compatible with standard RISC-V, so CHERI instructions, such as <<CRAM>>, that
 do not change the state of CHERI CSRs raise exceptions when CRE=0.
+This is the default behavior on reset.
 ====
 
 NOTE: xref:cheri_behavior_cre_mode[xrefstyle=short] summarizes the behavior of
@@ -530,7 +533,7 @@ NOTE: CRE is not required for the implicit access required by checking memory ac
 {REQUIRE_HYBRID_CSR}
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<ddc>> is a data pointer,
-so it does not need to be able to hold all possible invalid addresses.
+so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 
 .Unprivileged default data capability register
 include::img/ddcreg.edn[]

src/riscv-integration.adoc

@@ -99,7 +99,7 @@ instructions, such as <<AUIPC>> or <<JAL>>, in debug mode.
 include::img/pccreg.edn[]
 
 <<pcc>> is an executable
-vector, so it need not be able to hold all possible invalid addresses.
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 
 [#section_cap_instructions]
 === Capability Instructions
@@ -266,8 +266,9 @@ instruction following the jump is sealed and written to a *c* register.
 allows unconditional, indirect jumps to a target capability. The target capability is
 obtained by incrementing the capability in the *c* register operand by the
 sign-extended 12-bit offset, then setting the
-least significant bit of the result to zero. The target capability is unsealed if it is a sentry with zero offset. The capability
-with the address of the instruction following the jump is sealed
+least significant bit of the result to zero.
+The target capability is unsealed if it is a sentry and the instructions has a zero immediate offset.
+The capability with the address of the instruction following the jump is sealed
 and written to a *c* register.
 
 All jumps cause CHERI exceptions when a minimum sized instruction
@@ -569,7 +570,7 @@ encountered an exception. Otherwise, <<mepcc>> is never written by the
 implementation, though it may be explicitly written by software.
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<mepcc>> is an executable
-vector, so it does not need to be able to hold all possible invalid addresses.
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 Additionally, the capability in <<mepcc>> is unsealed when it is installed in
 <<pcc>> on execution of an <<MRET>> instruction.
 
@@ -938,7 +939,7 @@ The <<sepcc>> register is a renamed extension of <<sepc>> that is able to hold a
 capability. Its reset value is the <<infinite-cap>> capability.
 
 As shown in xref:CSR_exevectors[xrefstyle=short], <<sepcc>> is an executable
-vector, so it need not be able to hold all possible invalid addresses.
+vector, so it does not need to be able to hold all possible invalid addresses (see <<section_invalid_addr_conv>>).
 Additionally, the capability in <<sepcc>> is unsealed when it is installed in
 <<pcc>> on execution of an <<SRET>> instruction. The handling of <<sepcc>> is
 otherwise identical to <<mepcc>>, but in supervisor mode.