From f8592e332d2e154594d5c5fdfd015a19eb2c04f6 Mon Sep 17 00:00:00 2001 From: Tariq Kurd Date: Tue, 8 Oct 2024 09:21:06 +0100 Subject: [PATCH] typos and minor fixes (#409) I'll leave this one open for a while as we are bound to spot more problems --- src/attributes.adoc | 3 +++ src/cap-description.adoc | 6 ++++-- src/img/acperm_bit_field.edn | 2 +- src/insns/acperm_32bit.adoc | 2 ++ src/insns/hypv-virt-loadx.adoc | 10 ++++------ src/insns/modesw_32bit.adoc | 2 +- src/level-ext.adoc | 2 +- src/system.adoc | 6 +++--- src/tid-ext.adoc | 2 +- 9 files changed, 20 insertions(+), 15 deletions(-) diff --git a/src/attributes.adoc b/src/attributes.adoc index 7a0d9186..ed71f4cf 100644 --- a/src/attributes.adoc +++ b/src/attributes.adoc @@ -79,7 +79,10 @@ endif::[] :cap_rv32_mw_width: 10 :cap_rv64_mw_width: 14 :cap_rv32_perms_width: 5 +//including Zcherilevels, 6 without :cap_rv64_perms_width: 6 +//CL is not a permission, so 8 not 9 +:cap_rv64_perms_levels_width: 8 :cap_rv32_addr_width: 32 :cap_rv64_addr_width: 64 :cap_rv32_exp_width: 5 diff --git a/src/cap-description.adoc b/src/cap-description.adoc index e8a3ac5d..85109a46 100644 --- a/src/cap-description.adoc +++ b/src/cap-description.adoc @@ -169,6 +169,8 @@ Therefore, it is only possible to encode a subset of all combinations. ^| 64 | {cap_rv64_perms_width} | Separate bits for each architectural permission. |============================================================================== +NOTE: if {cheri_levels_ext_name} is supported then there are {cap_rv64_perms_levels_width} architectural permission bits. + For MXLEN=32, the permissions encoding is split into four quadrants. The quadrant is taken from bits [4:3] of the permissions encoding. The meaning for bits [2:0] are shown in <> for each quadrant. @@ -225,8 +227,8 @@ reserved values as if it were 0b00000 (no permissions). Future extensions may as meanings to the reserved bit patterns, in which case <> is allowed to report a non-zero value. -A {cap_rv64_perms_width}-bit vector encodes the permissions when MXLEN=64. In -this case, there is a bit per permission as shown in +A {cap_rv64_perms_width}-bit vector encodes the permissions when MXLEN=64 ({cap_rv64_perms_levels_width}-bit if {cheri_levels_ext_name} is supported). +In this case, there is a bit per permission as shown in xref:cap_perms_encoding64[xrefstyle=short]. A permission is granted if its corresponding bit is set, otherwise the capability does not grant that permission. diff --git a/src/img/acperm_bit_field.edn b/src/img/acperm_bit_field.edn index a3dbc83c..1412c887 100644 --- a/src/img/acperm_bit_field.edn +++ b/src/img/acperm_bit_field.edn @@ -25,7 +25,7 @@ (draw-box "1" {:span 1 :borders {}}) (draw-box "1" {:span 1 :borders {}}) (draw-box "1" {:span 1 :borders {}}) -(draw-box "8" {:span 6 :borders {}}) +(draw-box "10-SDPLEN" {:span 6 :borders {}}) (draw-box "SDPLEN" {:span 4 :borders {}}) (draw-box "1" {:span 1 :borders {}}) (draw-box "1" {:span 1 :borders {}}) diff --git a/src/insns/acperm_32bit.adoc b/src/insns/acperm_32bit.adoc index eb0acef4..346cbd4c 100644 --- a/src/insns/acperm_32bit.adoc +++ b/src/insns/acperm_32bit.adoc @@ -70,6 +70,8 @@ include::../img/acperm_bit_field.edn[] NOTE: The <>, <> and <> fields are only defined if the implementation supports <>. +NOTE: Even though being included here <> is not considered an architectural permission. + Exceptions:: include::require_cre.adoc[] diff --git a/src/insns/hypv-virt-loadx.adoc b/src/insns/hypv-virt-loadx.adoc index f9216529..fefc9d53 100644 --- a/src/insns/hypv-virt-loadx.adoc +++ b/src/insns/hypv-virt-loadx.adoc @@ -5,8 +5,6 @@ See <>. -<<< - [#HLVX_WU,reftext="HLVX.WU"] ==== HLVX.WU @@ -14,12 +12,12 @@ Synopsis:: Hypervisor virtual machine load from executable memory {cheri_cap_mode_name} Mnemonics:: -`hlv.hu rd, cs1` + -`hlv.wu rd, cs1` +`hlvx.hu rd, cs1` + +`hlvx.wu rd, cs1` {cheri_int_mode_name} Mnemonics:: -`hlv.hu rd, rs1` + -`hlv.wu rd, rs1` +`hlvx.hu rd, rs1` + +`hlvx.wu rd, rs1` Encoding:: include::wavedrom/hypv-virt-loadx.adoc[] diff --git a/src/insns/modesw_32bit.adoc b/src/insns/modesw_32bit.adoc index 8ec9b5cc..c24ada7d 100644 --- a/src/insns/modesw_32bit.adoc +++ b/src/insns/modesw_32bit.adoc @@ -24,7 +24,7 @@ Set the hart's current CHERI execution mode in <>. * MODESW.INT: If the current mode in <> is {cheri_cap_mode_name} ({CAP_MODE_VALUE}), then the <> in <> is set to {cheri_int_mode_name} ({INT_MODE_VALUE}). Otherwise no effect. NOTE: Implementations may optionally support executing <> and <> from the -program buffer while in debug mode. If supported them the <> in +program buffer while in debug mode. If supported then the <> in <> is set accordingly and used to control which mode to enter next time debug mode is entered. The CHERI execution mode is only controlled by the <> of <> in debug mode. diff --git a/src/level-ext.adoc b/src/level-ext.adoc index 4f72e2b7..365dfed3 100644 --- a/src/level-ext.adoc +++ b/src/level-ext.adoc @@ -100,7 +100,7 @@ endif::[] [#section_cap_level_change] === Changing capability levels and permissions -While capability levels are conceptually a label on the capability rather than a permission granted by the capability, they are adjusted using the <> instruction. +While capability levels (<>) are conceptually a label on the capability rather than a permission granted by the capability, they are adjusted using the <> instruction. This avoids the need for a dedicated instruction and allows reducing the level and removing <> in a single instruction. <<< diff --git a/src/system.adoc b/src/system.adoc index e59e1f2f..e56d7019 100644 --- a/src/system.adoc +++ b/src/system.adoc @@ -5,12 +5,12 @@ CHERI processors need memory systems which support the capability validity tags There are, or will soon be, a wide range of CHERI systems in existence from tiny IoT devices up to server chips. -There are two types of bus connections used in chips which contain CHERI CPUs: +There are two types of bus connections used in SoCs which contain CHERI CPUs: -. Tag-aware busses, where the bus protocol is extended to carry the tag along with the data. This is typically done using a user defined bit in the protocol. +. Tag-aware busses, where the bus protocol is extended to carry the tag along with the data. This is typically done using user defined bits in the protocol. .. These busses will read tags from memory (if tags are present in the target memory) and return them to the requestor. .. These busses will write the tag to memory as an extension of the data write. -. Non-tag aware busses, i.e. normal non-CHERI aware busses. +. Non-tag aware busses, i.e. current non-CHERI aware busses. .. Reads of tagged memory will not read the tag. .. Writes to tagged memory will clear the tag of any CLEN-aligned CLEN-wide memory location where any byte matches the memory write. diff --git a/src/tid-ext.adoc b/src/tid-ext.adoc index 9712e916..26ed39a6 100644 --- a/src/tid-ext.adoc +++ b/src/tid-ext.adoc @@ -7,7 +7,7 @@ software compartmentalization of CHERI programs. === Control and Status Registers (CSRs) -{tid_ext_name} adds two new CSRs to implement a trusted thread +{tid_ext_name} adds new CSRs to implement a trusted thread identifier (TID) used in compartmentalization. These CSRs are listed in xref:tid-mcsrnames-added[xrefstyle=short], xref:tid-scsrnames-added[xrefstyle=short],