Merge pull request #35 from tyshyu/main

Refine descriptions and propose some suggestions

chapter2.adoc

@@ -143,11 +143,11 @@ The following table shows (1) the error types, and (2) related control bits abou
 [cols="<1,<2,<5,<3"]
 |===
 3+h| Error type  h| Control bits
-   |0x00        2+| No error                        | N/A
-   |0x01        2+| Illegal read access             | Global^1.^ and local^2.^
-   |0x02        2+| Illegal write access            | Global and local
-   |0x03        2+| Illegal instruction fetch       | Global and local
-   |0x04        2+| Partial hit on a priority rule  | Global
+   |0x00        2+| No error                          | N/A
+   |0x01        2+| Illegal read access               | Global^1.^ and local^2.^
+   |0x02        2+| Illegal write access              | Global and local
+   |0x03        2+| Illegal instruction fetch         | Global and local
+   |0x04        2+| Partial hit on a priority rule    | Global
 .2+|0x05       .2+| Not hit any rule                
    | A transaction violates permissions on non-priority rules | Global and local
   a| Other cases:
@@ -156,8 +156,13 @@ The following table shows (1) the error types, and (2) related control bits abou
     * Receives a write access transaction when *HWCFG0.no_w* is 1
     * Receives an instruction fetch transaction when *HWCFG0.no_x* is 1
    | Global
-   |0x06        2+| Unknown RRID                    | Global
-   |0x07        2+| User-defined error              | Implementation-dependent
+   |0x06        2+| Unknown RRID                      | Global
+   |0x07        2+| Error due to stalled transactions.
+
+   Available if *ERR_CFG.stall_violation_en* is 1.
+   | Global
+   |0x08 ~ 0x0B 2+| N/A, reserved for future          | N/A
+   |0x0C ~ 0x0F 2+| User-defined error                | Implementation-dependent
 |===
 
 ^1.^ Bit *ie* or *rs* in *ERR_CFG*. It depends on which reaction (i.e., interrupt or bus error response).

chapter4.adoc

@@ -10,7 +10,7 @@ The term here "stable" refers to meeting the atomicity requirement. This implies
 === Programming Steps
 The general approach to the atomicity requirement has three major steps, conceptually described as follows:
 
-** Step 1: Stall related transactions. Before proceeding with any updates, delay checking the transactions that may be impacted. 
+** Step 1: Stall related transactions. Before proceeding with any updates, delay checking the transactions that may be impacted.
 ** Step 2: Update IOPMP's settings.
 ** Step 3: Resume stalled transactions. 
 
@@ -21,6 +21,8 @@ For step 1, it's important to verify if the necessary stalling transactions have
 In some cases, Step 1 and Step 3 may be skipped as long as no transaction check can interrupt Step 2. Updating MDs associated with a specific RRID to other MDs is an example.
 ====
 
+NOTE: While stalling transactions have taken place in Step 1, the IOPMP delays checking the stalled transactions until the IOPMP resumes the stalled transactions. For example, the IOPMP may wait the stalled transactions and/or respond retry messages to transaction requestors for the stalled transactions.
+
 === Stall Transactions
 For Step 1, it's possible to postpone all transactions until all updates are finished. However, this could cause unrelated transactions to experience unnecessary delays. This might not be tolerable for devices that require low latency, like a display controller that periodically retrieves a frame from its video buffer. This section explains the mechanism that only stalls specific transactions to prevent the aforementioned scenario and ensure the atomicity requirement. All the features mentioned below are optional.
 
@@ -76,7 +78,7 @@ To query if all transactions associated with a specific RRID are stalled, do the
 
 [NOTE]
 ====
-In certain implementations, rather than stalling the related transactions, the system may opt to fault the checking transactions during an IOPMP atomic update. The procedure for faulting checking transactions is identical to Steps 1-3 mentioned above, except that, instead of stalling and delaying the transactions, transactions will be faulted and cannot be resumed. Faulting transactions can be advantageous if the system lacks sufficient buffer capacity to record and store all transactions during the IOPMP programming process. To select faulting over stalling, one should set ERR_CFG.fault_mode to 1. If any transaction is faulted due to MDSTALL enabling, the error information shall be logged in ERR_REQINFO, where ERR_REQINFO.etype = 0x7.
+In certain implementations, rather than stalling the related transactions, the system may opt to fault the checking transactions during an IOPMP atomic update. The procedure for faulting checking transactions is identical to Steps 1-3 mentioned above, except that, instead of stalling and delaying the transactions, transactions will be faulted and cannot be resumed. Faulting transactions can be advantageous if the system lacks sufficient buffer capacity to record and store all transactions during the IOPMP programming process. To select faulting over stalling, one should set *ERR_CFG.stall_violation_en* to 1. If any transaction is faulted due to the stalled transactions, the error information shall be logged in *ERR_REQINFO*, where *ERR_REQINFO.etype* = 0x7 (error due to stalled transactions).
 ====
 
 === Implementation Options

chapter5.adoc

@@ -260,7 +260,7 @@ To suppress an error response on an IOPMP rule violation.
 
 * 0x0: the IOPMP triggers interrupt by wired interrupt
 * 0x1: the IOPMP triggers interrupt by MSI
-|{set:cellbgcolor:#FFFFFF}fault_mode  |4:4  |WARL   |IMP        | When MDSTALL is set, fault the transactions if the corresponding RRID is not exempt.
+|{set:cellbgcolor:#FFFFFF}stall_violation_en  |4:4  |WARL   |IMP        | Indicates whether the IOPMP faults stalled transactions. When the bit is set, the IOPMP faults the transactions if the corresponding RRID is not exempt from stall.
 |{set:cellbgcolor:#FFFFFF}rsv1    |7:5    |ZERO   |0     | Must be zero on write, reserved for future
 |{set:cellbgcolor:#FFFFFF}msidata |18:8   |WARL   |IMP   | The data to trigger MSI
 |{set:cellbgcolor:#FFFFFF}rsv2    |31:19  |ZERO   |0     | Must be zero on write, reserved for future
@@ -297,12 +297,13 @@ h|Field                         |Bits       |R/W    |Default    |Description
 - 0x04 = partial hit on a priority rule
 - 0x05 = not hit any rule
 - 0x06 = unknown RRID
-- 0x07 = error due to MDSTALL
-- 0x08 ~0xf = user-defined error
+- 0x07 = error due to stalled transactions. Available if *ERR_CFG.stall_violation_en* is 1.
+- 0x08 ~ 0xB = N/A, reserved for future
+- 0x0C ~ 0xF = user-defined error
 |{set:cellbgcolor:#FFFFFF} svc   |8:8    |R      |0          |Indicate there is a subsequent violation caught in *ERR_MFR*.
 Implemented only for *HWCFG0.mfr_en*=1, otherwise, ZERO.
 
-|{set:cellbgcolor:#FFFFFF} rsv2   |31:9    |ZERO      |0          |Must be zero on write, reserved for future
+|{set:cellbgcolor:#FFFFFF} rsv   |31:9    |ZERO      |0          |Must be zero on write, reserved for future
 |===
 When the bus matrix doesn't have a signal to indicate an instruction fetch, the *ttype* and *etype* can never return "instruction fetch" (0x03) and "instruction fetch error" (0x03), respectively.
 

iopmp.adoc

@@ -1,8 +1,8 @@
 [[header]]
 :description: RISC-V IOPMP Architecture Specification
 :company: RISC-V.org
-:revdate: Nov, 2024
-:revnumber: 0.9.2-RC2
+:revdate: Dec, 2024
+:revnumber: 0.9.2-RC3
 :revremark: This document is in development. Assume everything can change. See http://riscv.org/spec-state for details.
 :url-riscv: http://riscv.org
 :doctype: book