Ensure GCPERM/ACPERM result is forwards-compatible with software (#501)

When new extensions add permissions that are subsets of current
permissions
(e.g. Zcherilevels refines loads/stores), then a system that does not
support these permissions should still report ones in GCPERM to ensure that
code that inspects permissions knows that the load/store behaves as if all
of these permission bits were set.

We reserve the low 24 bits as ones (to be used as refinements of the current
permissions) and the upper 8 (40 for RV64) bits as zeros (to be used for
new permissions that aren't subsets (e.g. seal/unseal/compartment ID).

Partially addresses #502

src/img/acperm_bit_field.edn

@@ -6,13 +6,14 @@
 (def left-margin 100)
 (def right-margin 100)
 (def boxes-per-row 32)
-(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "3" "4" "5" "6" "" "" "SDPLEN+5" "" "" "" "" "" "15" "16" "17" "18" "19" "" "" "" "" "" "" "" "" "" "" "" "XLEN-1"])})
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "3" "4" "5" "6" "" "" "SDPLEN+5" "" "" "" "" "" "15" "16" "17" "18" "19" "" "23" "" "" "" "" "" "" "" "" "" "XLEN-1"])})
 
-(draw-box "Reserved" {:span 13})
+(draw-box "Reserved 0" {:span 10})
+(draw-box "Reserved 1" {:span 3})
 (draw-box "R"        {:span 1})
 (draw-box "X"        {:span 1})
 (draw-box "ASR"      {:span 1})
-(draw-box "Reserved" {:span 6})
+(draw-box "Reserved 1" {:span 6})
 (draw-box "SDP"      {:span 4})
 (draw-box "C"        {:span 1})
 (draw-box "CL"       {:span 1})
@@ -21,7 +22,8 @@
 (draw-box "LM"       {:span 1})
 (draw-box "W"        {:span 1})
 
-(draw-box "XLEN-19"   {:span 13 :borders {}})
+(draw-box "XLEN-23"   {:span 10 :borders {}})
+(draw-box "5"         {:span 3 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})

src/insns/acperm_32bit.adoc

@@ -80,9 +80,14 @@ The behavior of currently illegal combinations from <<acperm_rules>> is to clear
 [#acperm_bit_field]
 include::../img/acperm_bit_field.edn[]
 
-NOTE: The <<el_perm,EL>>, <<sl_perm,SL>> and <<section_cap_level,CL>> fields are only defined if the implementation supports <<cheri_levels_ext,{cheri_levels_ext_name}>>.
+NOTE: The <<el_perm,EL>>, <<sl_perm,SL>> and <<section_cap_level,CL>> fields are only modifiable if the implementation supports <<cheri_levels_ext,{cheri_levels_ext_name}>>.
 
-NOTE: Even though being included here <<section_cap_level,CL>> is not considered an architectural permission.
+
+NOTE: Even though included here <<section_cap_level,CL>> is not considered an architectural permission.
+
+
+NOTE: If a future extension adds a new permission that is a refinement of an existing permission (e.g. finer-grained <<asr_perm>>), then clearing the superset must also clear the refined permission.
+This ensures software forward-compatibility: for example, a kernel that does not know about finer-grained <<asr_perm>> subsets must still be able to prevent all access to privileged instructions and CSRs by clearing <<asr_perm>>.
 
 Exceptions::
 include::require_cre.adoc[]

src/insns/gcperm_32bit.adoc

@@ -25,6 +25,7 @@ Convert the unpacked AP permissions as well as the SDP fields of capability `cs1
 into a bit field, with the format shown in xref:gcperm_bit_field[xrefstyle=short],
 and write the result to `rd`. A bit set to 1 in the bit field indicates that
 `cs1` grants the corresponding permission.
+All bits in the `[0:23]` range that are reserved or assigned to extensions that are not implemented by the current hart always report 1.
 +
 If the AP field cannot be produced by <<ACPERM>> then all architectural
 permission bits in `rd` are set to 0.
@@ -33,6 +34,12 @@ permission bits in `rd` are set to 0.
 [#gcperm_bit_field]
 include::../img/acperm_bit_field.edn[]
 
+NOTE: When {cheri_levels_ext_name} is not implemented, the `CL`, `SL`, and `EL` fields always report 1.
+This ensures forwards-compatibility since loads/stores on a core without {cheri_levels_ext_name} behave as if these permissions are always present.
+
+NOTE: Any future extension that defines new permission that are a refinement of existing permissions (e.g. finer-grained <<asr_perm>>) must be allocated to the bits that are currently reported as 1 to ensure forward-compatibility.
+Completely new permissions (e.g. sealing) should use the bits that are reported as zero in the current specification.
+
 Exceptions::
 include::require_cre.adoc[]