From 54143358740ae704b4f743a010bcaf399de41e99 Mon Sep 17 00:00:00 2001 From: tyshyu <172017981+tyshyu@users.noreply.github.com> Date: Fri, 3 Jan 2025 17:32:09 +0800 Subject: [PATCH 1/3] Update version date Signed-off-by: tyshyu <172017981+tyshyu@users.noreply.github.com> --- iopmp.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/iopmp.adoc b/iopmp.adoc index a40f0bc..f0a3594 100644 --- a/iopmp.adoc +++ b/iopmp.adoc @@ -1,7 +1,7 @@ [[header]] :description: RISC-V IOPMP Architecture Specification :company: RISC-V.org -:revdate: Dec, 2024 +:revdate: Jan, 2025 :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 From 5c21dfd87054b4531779495d92262ed840495f22 Mon Sep 17 00:00:00 2001 From: tyshyu <172017981+tyshyu@users.noreply.github.com> Date: Fri, 3 Jan 2025 17:52:22 +0800 Subject: [PATCH 2/3] Update Chapter 2, 4 and 5 Refine faulting stalled transaction and move related description from Section 4.6 to Section 4.2.1. Refine Section 2.6 and 2.7 and error type for permission violation on non-priority entries should be 0x01~0x03. Refine description about error type = 0x07. Update reserved and user-defined error types. Reset value of ENTRY_CFG(i).sire/siwe/sixe/sere/sewe/sexe should be IMP. Reset value of ERR_MFR.svs should be 0. Label tables. Mark optional on some registers in the table 3 (Chapter 5). Signed-off-by: tyshyu <172017981+tyshyu@users.noreply.github.com> --- chapter2.adoc | 60 +++++++++++++++++++++++++-------------------------- chapter4.adoc | 24 ++++++++++++++------- chapter5.adoc | 39 +++++++++++++++++---------------- 3 files changed, 65 insertions(+), 58 deletions(-) diff --git a/chapter2.adoc b/chapter2.adoc index e8e72d7..56890c4 100644 --- a/chapter2.adoc +++ b/chapter2.adoc @@ -3,7 +3,7 @@ This document refers to the term “secure monitor” as the software responsible for managing security-related tasks, including the programming of IOPMPs. The secure monitor is not restricted to operating on a single CPU or hart; instead, it has the flexibility to be distributed across multiple CPUs. -{set:cellbgcolor:#0000} +.Glossary and Acronyms [cols="<1,<3",stripes=even] |=== 2+h|Glossary/ Acronyms{set:cellbgcolor:#D3D3D3} @@ -68,11 +68,11 @@ IOPMP entries exhibit partial prioritization. Entries with indices smaller than NOTE: The specification incorporates both priority and non-priority entries due to considerations of security, latency, and area. Priority entries, which are locked, safeguard the most sensitive data, even in the event of secure software being compromised. However, implementing a large number of these priority entries results in higher latency and increased area usage. On the other hand, non-priority entries are treated equally and can be cached in smaller numbers. This approach reduces the amortized latency, power consumption, and area when the locality is sufficiently high. Thus, the mix of entry types in the specification allows for a balance between security and performance. -The entry with the highest priority that (1) matches any byte of the incoming transaction and (2) is associated with the RRID carried by the transaction determines whether the transaction is legal. If the matching entry is priority entry, the matching entry must match all bytes of a transaction, or the transaction is illegal with error type = "partial hit on a priority rule" (0x04), irrespective of its permission. If a priority entry is matched but doesn't grant a transaction permission to operate, the transaction is illegal with error type = "illegal read access" (0x01), "illegal write access" (0x02) or "illegal instruction fetch" (0x03), depending on its transaction type. +The entry with the highest priority that (1) matches any byte of the incoming transaction and (2) is associated with the RRID carried by the transaction determines whether the transaction is legal. If the matching entry is priority entry, the matching entry must match all bytes of a transaction, or the transaction is illegal with error type = "partial hit on a priority rule" (0x04), irrespective of its permission. An entry has own permission and permission from Memory Domain to grant a transaction permission. If a priority entry is matched but doesn't grant transaction permission to operate, the transaction is illegal with error type = "illegal read access" (0x01) for read access transaction, "illegal write access" (0x02) for write access transaction, or "illegal instruction fetch" (0x03) for instruction fetch transaction. -Let's consider a non-priority entry matching all bytes of a transaction. It is legal if the entry grants the transaction permission to operate. When multiple non-priority entries match all bytes of a transaction and one of them allows the transaction, the transaction is legal. If none of them allows, the transaction is illegal with error code = "not hit any rule" (0x05). +Let's consider a non-priority entry matching all bytes of a transaction. It is legal if the entry grants the transaction permission to operate. When multiple non-priority entries match all bytes of a transaction and one of them allows the transaction, the transaction is legal. If none of them allows, the transaction is illegal with error type = "illegal read access" (0x01) for read access transaction, "illegal write access" (0x02) for write access transaction, or "illegal instruction fetch" (0x03) for instruction fetch transaction. -Finally, if no such above entry exists, the transaction is illegal with error code = "not hit any rule" (0x05). +Finally, if no such above entry exists, the transaction is illegal with error type = "not hit any rule" (0x05). [caption="Figure {counter:image}: ", reftext="Figure {image}"] @@ -91,24 +91,24 @@ Upon detecting an illegal transaction, the IOPMP could initiate three of the fol The interrupt enabling on an IOPMP violation can be configured globally via *ERR_CFG* register or optionally locally through the *ENTRY_CFG* register for each entry. The *ERR_CFG.ie* bit serves as the global interrupt enable configure bit. *HWCFG0.peis* is 1 if an implementation supports *sire*, *siwe*, or *sixe*. Every entry _i_ has three optional interrupt suppressing bits in register *ENTRY_CFG(_i_)*, *sire*, *siwe*, and *sixe* to suppress interrupt triggering due to illegal reads, illegal writes and illegal instruction fetches on the corresponding entry, respectively. Such local interrupt control mechanism can be beneficial in scenarios such as configuring guard regions for speculative access handling. The interrupt pending indication is equivalent to the error valid indication, both are flagged through the *ERR_INFO.v* bit. An IOPMP interrupt will be triggered when a transaction is illegal and the interrupt is not suppressed. An IOPMP triggers interrupt by global interrupt enable configure bit *ie* and suppressing bits (*sire*, *siwe*, or *sixe*) in entries if a transaction only violates permissions on entries and *peis* is 1. On the other hand, if a transaction doesn't only violate permissions on entries, an IOPMP triggers interrupt only by global interrupt enable configure bit *ie*. The permissions include permission bits in entries (*ENTRY_CFG(_i_).r/w/x*) and permission bits from SRCMD table (please refer <<#SECTION_3_2, SRCMD Table Formats>> for the details) to corresponding entries. The relation of interrupt control with interrupt suppression bits for an illegal transaction can be more precisely described as follows: -An entry indexed by _i_ has the highest priority and matches all bytes of the illegal transaction, and the illegal transaction is: +An entry indexed by _i_ has the highest priority and matches all bytes of the illegal transaction, and error type of the illegal transaction is: -* Read access transaction: + +* Illegal read access (0x01): + *ERR_CFG.ie* && !*ENTRY_CFG(_i_).sire* -* Write access transaction: + +* Illegal write access (0x02): + *ERR_CFG.ie* && !*ENTRY_CFG(_i_).siwe* -* Instruction fetch transaction: + +* Illegal instruction fetch (0x03): + *ERR_CFG.ie* && !*ENTRY_CFG(_i_).sixe* For some cases with multiple matched non-priority entries, the more detailed relation is: -Entries indexed by _i_~0~, _i_~1~, …​, _i~N~_ match all bytes of the illegal transaction, and the illegal transaction is: +Entries indexed by _i_~0~, _i_~1~, …​, _i~N~_ match all bytes of the illegal transaction, and error type of the illegal transaction is: -* Read access transaction: + +* Illegal read access (0x01): + *ERR_CFG.ie* && ( !*ENTRY_CFG(_i_~0~).sire* || !*ENTRY_CFG(_i_~1~).sire* || ... || !*ENTRY_CFG(_i~N~_).sire* ) -* Write access transaction: + +* Illegal write access (0x02): + *ERR_CFG.ie* && ( !*ENTRY_CFG(_i_~0~).siwe* || !*ENTRY_CFG(_i_~1~).siwe* || ... || !*ENTRY_CFG(_i~N~_).siwe* ) -* Instruction fetch transaction: + +* Instruction fetch transaction (0x03): + *ERR_CFG.ie* && ( !*ENTRY_CFG(_i_~0~).sixe* || !*ENTRY_CFG(_i_~1~).sixe* || ... || !*ENTRY_CFG(_i~N~_).sixe* ) @@ -116,30 +116,33 @@ Transactions that violates the IOPMP rule will by default yield a bus error. Add In the same way, the bus error response behavior can be set up globally and individually for each IOPMP entry. *ERR_CFG.rs* globally suppresses returning a bus error on illegal access. When global suppression is disabled, individual per-entry suppression is possible using *sere*, *sewe*, and *sexe* for illegal read, illegal write, and illegal instruction fetch, respectively. *HWCFG0.pees* is 1 if an IOPMP implements *sere*, *sewe*, and *sexe*. An IOPMP will respond with a bus error when a transaction is illegal and the bus error is not suppressed. Bus error response behavior of an IOPMP is controlled by global interrupt enable configure bit *rs* and suppressing bits (*sere*, *sewe*, or *sexe*) in entries if a transaction only violates permissions on entries and *pees* is 1. On the other hand, if a transaction doesn't only violate permissions on entries, bus error response behavior of an IOPMP is controlled only by global interrupt enable configure bit *ie*. The permissions include permission bits in entries (*ENTRY_CFG(_i_).r/w/x*) and permission bits from SRCMD table (please refer <<#SECTION_3_2, SRCMD Table Formats>> for the details) to corresponding entries. The relation of bus error response suppression control with supression bits in entries for an illegal transaction can be more precisely described as follows: -An entry indexed by _i_ has the highest priority and matches all bytes of the illegal transaction, and the illegal transaction is: +An entry indexed by _i_ has the highest priority and matches all bytes of the illegal transaction, and error type of the illegal transaction is: -* Read access transaction: + +* Illegal read access (0x01): + *ERR_CFG.ie* && !*ENTRY_CFG(_i_).sere* -* Write access transaction: + +* Illegal write access (0x02): + *ERR_CFG.ie* && !*ENTRY_CFG(_i_).sewe* -* Instruction fetch transaction: + +* Illegal instruction fetch (0x03): + *ERR_CFG.ie* && !*ENTRY_CFG(_i_).sexe* For some cases with multiple matched non-priority entries, the more detailed relation is: -Entries indexed by _i_~0~, _i_~1~, …​, _i~N~_ match all bytes of the illegal transaction, and the illegal transaction is: +Entries indexed by _i_~0~, _i_~1~, …​, _i~N~_ match all bytes of the illegal transaction, and error type of the illegal transaction is: -* Read access transaction: + +* Illegal read access (0x01): + !*ERR_CFG.rs* && ( !*ENTRY_CFG(_i_~0~).sere* || !*ENTRY_CFG(_i_~1~).sere* || ... || !*ENTRY_CFG(_i~N~_).sere* ) -* Write access transaction: + +* Illegal write access (0x02): + !*ERR_CFG.rs* && ( !*ENTRY_CFG(_i_~0~).sewe* || !*ENTRY_CFG(_i_~1~).sewe* || ... || !*ENTRY_CFG(_i~N~_).sewe* ) -* Instruction fetch transaction: + +* Illegal instruction fetch (0x03): + !*ERR_CFG.rs* && ( !*ENTRY_CFG(_i_~0~).sexe* || !*ENTRY_CFG(_i_~1~).sexe* || ... || !*ENTRY_CFG(_i~N~_).sexe* ) -The error capture record maintains the specifics of the first illegal access detected, except if the following two conditions are held: (1) any interrupt-suppress bit regarding the access is set, and (2) no bus error is returned. New error capture only occurs when there is no currently pending error, namely *ERR_INFO.v* is ‘0’. If a pending error exists (*v* is ‘1’), the record will not be updated, even if a new illegal access is detected. In other words, *v* indicates whether the content of the capture record is valid and should be intentionally cleared in order to capture subsequent illegal accesses. One can write 1 to the bit to clear it. The error capture record is optional. If it is not implemented, *v* should be wired to zero. One can implement the error capture record but not *ERR_REQID.eid*. In this case, *ERR_REQID.eid* should be wired to 0xffff. +The error capture record maintains the specifics of the first illegal access detected, except if the following two conditions are held: (1) any interrupt-suppress bit regarding the access is set, and (2) no bus error is returned. New error capture only occurs when there is no currently pending error, namely *ERR_INFO.v* is ‘0’. If a pending error exists (*v* is ‘1’), the record will not be updated, even if a new illegal access is detected. In other words, *v* indicates whether the content of the capture record is valid and should be intentionally cleared in order to capture subsequent illegal accesses. One can write 1 to the bit to clear it. The error capture record is optional. If it is not implemented, *v* should be wired to zero. One can implement the error capture record but not *ERR_REQID.eid*. In this case, *eid* should be wired to 0xffff. + +If a transaction violates IOPMP rules on multiple non-priority entries which don't suppress interrupt or bus error respose, the *ERR_REQID.eid* should be one of the entries. The following table shows (1) the error types, and (2) related control bits about interrupt triggering and bus error response if the IOPMP supports local control bits (*HWCFG0.peis* is 1 and/or *HWCFG0.pees* is 1): +.Error types and corresponding control bits [cols="<1,<2,<5,<3"] |=== 3+h| Error type h| Control bits @@ -148,21 +151,16 @@ The following table shows (1) the error types, and (2) related control bits abou |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: - - * No entry matches all bytes of a transaction + |0x05 | Not hit any rule + a|* No entry matches all bytes of a transaction * 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+| Error due to stalled transactions. - - Available if *ERR_CFG.stall_violation_en* is 1. + |0x07 2+| Error due to stalled transactions. Please refer <<#SECTION_4_2_1, Faulting stalled transactions>>. | Global - |0x08 ~ 0x0B 2+| N/A, reserved for future | N/A - |0x0C ~ 0x0F 2+| User-defined error | Implementation-dependent + |0x08 ~ 0x0D 2+| N/A, reserved for future | N/A + |0x0E ~ 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). diff --git a/chapter4.adoc b/chapter4.adoc index 111c3b6..ed4ad10 100644 --- a/chapter4.adoc +++ b/chapter4.adoc @@ -23,6 +23,17 @@ In some cases, Step 1 and Step 3 may be skipped as long as no transaction check 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. +[#SECTION_4_2_1] +==== Faulting stalled transactions +Faulting stalled transactions can be allowed. To allow faulting over stalling when the IOPMP has no capacity to handle more stalls, one should set *ERR_CFG.stall_violation_en* to 1 before Step 1. If any transaction is faulted due to the stalled transactions, the error information shall be logged in *ERR_REQINFO*, where *ERR_REQINFO.etype* = 0x07 (error due to stalled transactions). The procedure for faulting checking transactions is identical to Steps 1-3 mentioned above, except that, besides stalling and delaying the transactions, transactions can be faulted and cannot be resumed if the IOPMP can't handle more stalled transactions. + +[NOTE] +==== +In certain implementations, rather than stalling the related transactions, the system may opt to fault the checking transactions during an IOPMP atomic update. Faulting transactions can be advantageous if the system lacks sufficient buffer capacity to record and store all transactions during the IOPMP programming process. + +This function also can prevent the risk of deadlock in some systems. If an implementation or a system doesn't have sufficient buffer capacity for handling all stalled transactions during programming, the stalled transactions may backpressure from receiver port of the IOPMP and then occur hang on the port due to its implementation limitation. Therefore, the hang on the port potentially causes a deadlock in the system since transactions for programming IOPMP during Step 2 and Step 3 have the possibility to hang indirectly in the circumstance. +==== + === 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. @@ -33,7 +44,7 @@ A conceptual internal signal rrid_stall has the same number of bits as the RRIDs [.text-center] `rrid_stall[_s_] <= MDSTALL.exempt ^ ( Reduction_OR (SRCMD(_s_).md & stall_by_md));` -As to SRCMD table Format 2, *SRCMD(_s_).md[_m_]* in the above equation is: ‘0’ for all an umimplemented memory domain _m_ and ‘1’ for an implemented memory domain _m_ because every RRID associates all implemented MDs. +As to SRCMD table Format 2, *SRCMD(_s_).md[_m_]* in the above equation is: ‘0’ for all umimplemented memory domain _m_ and ‘1’ for an implemented memory domain _m_ because every RRID associates all implemented MDs. For any unimplemented memory domain, the corresponding bit in *MDSTALL.md* or *MDSTALLH.mdh* should be wired to 0. @@ -61,7 +72,7 @@ In Step 1 of programming IOPMP, *MDSTALL* can be written at most once and before After writing any non-zero value to *MDSTALL*, *MDSTALL.is_stalled* must be asserted within some time, no matter whether any RRID is stalled. The software polling the status bit doesn't need to consider whether any RRID will be stalled. On the other hand, after writing zero to *MDSTALLH* (if any) and then *MDSTALL*, *MDSTALL.is_stalled* must be de-asserted within some time. ==== -Based on the aforementioned, complete steps to program an IOPMP are suggested. +Based on the aforementioned, complete steps to program an IOPMP should be followed. ** Step 1.1: write MDSTALL once // exactly once ** Step 1.2: write RRIDSCP zero or more times @@ -76,11 +87,6 @@ Some steps may be skipped according to the actual implementation. To query if all transactions associated with a specific RRID are stalled, do the following. First, write 0 to *RRIDSCP.op* and the RRID you want to query to *RRIDSCP.rrid*. Then, read back *RRIDSCP*. The readback of *RRIDSCP.stat* = 1 means that transactions with the queried RRID have stalled, that is, the corresponding bit in rrid_stall is 1. If the value is 2, it means they are not stalled. A value of 3 indicates an unimplemented or unselectable RRID in *RRIDSCP.rrid*. *RRIDSCP.stat* is in the same location as *RRIDSCP.op* on a write. *RRIDSCP.rrid* should keep the last written legal RRID and *RRIDSCP.stat* reflects the current state of this RRID. This method is considered an indirect way to read rrid_stall. -[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.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 All registers described in this chapter are optional. Moreover, these features could be partially implemented. In *MDSTALL.md* and *MDSTALLH.mdh*, not every bit should be implemented even though the corresponding MD is implemented. An unimplemented bit means unselectable and should be wired to zero. To test which bits are implemented, one can write all 1's to *MDSTALL.md* and *MDSTALLH.mdh* and then read them back. An implemented bit returns 1. @@ -88,8 +94,10 @@ If an IOPMP implementation has fewer than 32 memory domains, *MDSTALLH* should b NOTE: An example of partial implementation of *MDSTALL.md*/*MDSTALLH.mdh* is a system with a display controller, which is a latency-sensitive device. On updating the IOPMP, the transactions initiated from the display controller should not be stalled. Thus, one can always use *MDSTALL.exempt*=1 and *MDSTALL.md[_j_]*=1, where MD _j_ is the memory domain for the frame buffer that the display controller keeps accessing. Thus, the system only needs to implement *MDSTALL.md[_j_]*. -If whole *MDSTALL* is not implemented, *MDSTALL* and *MDSTALLH* should always return zero. +If whole *MDSTALL* is not implemented, *MDSTALL*, *MDSTALLH* and *ERR_CFG.stall_violation_en* should always return zero. If *RRIDSCP* is not implemented, it always returns zero. One can test if it is implemented by writing a zero and then reading it back. Any IOPMP implementing *RRIDSCP* should not return a zero in *RRIDSCP.stat* in this case. It is unnecessary to allow every implemented RRID to be selectable by *RRIDSCP.rrid*. If an unimplemented or unselectable RRID is written into *RRIDSCP.rrid*, it returns *RRIDSCP.stat* = 3. + +*ERR_CFG.stall_violation_en* is a WARL field so it can be programmable or fixed. \ No newline at end of file diff --git a/chapter5.adoc b/chapter5.adoc index 1ff19cc..55e4c6a 100644 --- a/chapter5.adoc +++ b/chapter5.adoc @@ -2,6 +2,7 @@ == Registers If an optional register is not implemented, the behavior is implementation-dependent unless otherwise specified. An optional field in an implemented register means being WARL. If it is not programmable, it should be hardwired to value matching its meaning and should not cause any effect when written. +.Register summary [cols="<3,<6,<14",options="header"] |=== |OFFSET |Register |Description @@ -17,20 +18,20 @@ If an optional register is not implemented, the behavior is implementation-depen |RRIDSCP 2+|{set:cellbgcolor:#D3D3D3} Configuration Protection -|{set:cellbgcolor:#FFFFFF} MDLCK/MDLCKH | Lock register for SRCMD table. -|{set:cellbgcolor:#FFFFFF} MDCFGLCK | Lock register for MDCFG table. +|{set:cellbgcolor:#FFFFFF} MDLCK/MDLCKH | (Optional) lock register for SRCMD table. +|{set:cellbgcolor:#FFFFFF} MDCFGLCK | (Optional) lock register for MDCFG table. |{set:cellbgcolor:#FFFFFF} ENTRYLCK | Lock register for IOPMP entry array. 2+|{set:cellbgcolor:#D3D3D3} Error Reporting |{set:cellbgcolor:#FFFFFF} ERR_CFG | Indicates the reactions for the violations -|{set:cellbgcolor:#FFFFFF} ERR_INFO | Indicates the information regarding captured violations. -|ERR_REQID | Indicates the RRID and entry index regarding the first captured violation. -|{set:cellbgcolor:#FFFFFF} ERR_REQADDR/ERR_REQADDRH | Indicates request address regarding the first captured violation. +|{set:cellbgcolor:#FFFFFF} ERR_INFO | (Optional) indicates the information regarding captured violations. +|ERR_REQID | (Optional) indicates the RRID and entry index regarding the first captured violation. +|{set:cellbgcolor:#FFFFFF} ERR_REQADDR/ERR_REQADDRH | (Optional) indicates request address regarding the first captured violation. |ERR_MFR| (Optional) To retrieve which RRIDs make subsequent violations. |ERR_MSIADDR/ERR_MSIADDRH| (Optional) The address to trigger MSI. |ERR_USER(0:7) | (Optional) User-defined violation information. -.2+|0x0800 2+|{set:cellbgcolor:#D3D3D3} MDCFG Table, _m_ = 0...*HWCFG0.md_num*-1 +.2+|0x0800 2+|{set:cellbgcolor:#D3D3D3} MDCFG Table, _m_ = 0...*HWCFG0.md_num*-1, only available when *HWCFG0.mdcfg_fmt* = 0. |{set:cellbgcolor:#FFFFFF}MDCFG(_m_) |MD config register, which is to specify the indices of IOPMP entries belonging to a MD. .6+|0x1000 2+|{set:cellbgcolor:#D3D3D3} SRCMD Table, _s_ = 0...*HWCFG1.rrid_num*-1, only available when *HWCFG0.srcmd_fmt* = 0. @@ -59,7 +60,7 @@ INFO registers are use to indicate the IOPMP instance configuration info. 5+h|0x0000 h|Field |Bits |R/W |Default |Description |{set:cellbgcolor:#FFFFFF}vendor|23:0 |R |IMP |The JEDEC manufacturer ID. -|specver |31:24 |R |IMP |The specification version +|specver |31:24 |R |IMP |The specification version. (it will be defined in ratified version). |=== [cols="<2,<1,<1,<1,<6"] @@ -187,9 +188,9 @@ h|Field |Bits |R/W |Default |Description * 2: don't stall transactions associated with selected RRID * 3: reserved |{set:cellbgcolor:#FFFFFF}stat |31:30 |R |0 a| -* 0: *RRIDSCP* not implemented +* 0: *RRIDSCP* is not implemented * 1: transactions associated with selected RRID are stalled -* 2: transactions associated with selected RRID not are stalled +* 2: transactions associated with selected RRID are not stalled * 3: unimplemented or unselectable RRID |=== @@ -297,9 +298,9 @@ 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 stalled transactions. Available if *ERR_CFG.stall_violation_en* is 1. -- 0x08 ~ 0xB = N/A, reserved for future -- 0x0C ~ 0xF = user-defined error +- 0x07 = error due to stalled transactions. It can happen when *ERR_CFG.stall_violation_en* is 1. +- 0x08 ~ 0x0D = N/A, reserved for future +- 0x0E ~ 0x0F = 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. @@ -343,7 +344,7 @@ h|Field |Bits |R/W |Default |Description |{set:cellbgcolor:#FFFFFF}svw |15:0 |R |DC | Subsequent violations in the window indexed by *svi*. *svw[_j_]*=1 for the at lease one subsequent violation issued from RRID= *svi**16 + _j_. |{set:cellbgcolor:#FFFFFF}svi |27:16 |WARL |0 | Window's index to search subsequent violations. When read, IOPMP sequentially scans all windows from *svi* until one subsequent violation is found. Once the last available window is scanned, the next window to be scanned is the first record window (index is 0). *svi* indexes the found subsequent violation or *svi* has been rounded back to the same value. After read, the window's content, *svw*, should be clean. |{set:cellbgcolor:#FFFFFF}rsv |30:28 |ZERO |0 |Must be zero on write, reserved for future -|{set:cellbgcolor:#FFFFFF}svs |31:31 |R |DC a| The status of this window's content: +|{set:cellbgcolor:#FFFFFF}svs |31:31 |R |0 a| The status of this window's content: * 0x0 : no subsequent violation found * 0x1 : subsequent violation found @@ -503,23 +504,23 @@ h|Field |Bits |R/W |Default |Description * 0x1: TOR * 0x2: NA4 * 0x3: NAPOT -|{set:cellbgcolor:#FFFFFF}sire |5:5 |WARL |0 | To suppress interrupt for an illegal read access caught by the entry +|{set:cellbgcolor:#FFFFFF}sire |5:5 |WARL |IMP | To suppress interrupt for an illegal read access caught by the entry -|{set:cellbgcolor:#FFFFFF}siwe |6:6 |WARL |0 |Suppress interrupt for write violations caught by the entry +|{set:cellbgcolor:#FFFFFF}siwe |6:6 |WARL |IMP |Suppress interrupt for write violations caught by the entry -|{set:cellbgcolor:#FFFFFF}sixe |7:7 |WARL |0 |Suppress interrupt on an illegal instruction fetch caught by the entry +|{set:cellbgcolor:#FFFFFF}sixe |7:7 |WARL |IMP |Suppress interrupt on an illegal instruction fetch caught by the entry -|{set:cellbgcolor:#FFFFFF}sere |8:8 |WARL |0 a| Suppress the (bus) error on an illegal read access caught by the entry +|{set:cellbgcolor:#FFFFFF}sere |8:8 |WARL |IMP a| Suppress the (bus) error on an illegal read access caught by the entry * 0x0: respond an error if *ERR_CFG.rs* is 0x0. * 0x1: do not respond an error. User to define the behavior, e.g., respond a success with an implementation-dependent value to the initiator. -|{set:cellbgcolor:#FFFFFF}sewe |9:9 |WARL |0 a|{set:cellbgcolor:#FFFFFF} Suppress the (bus) error on an illegal write access caught by the entry +|{set:cellbgcolor:#FFFFFF}sewe |9:9 |WARL |IMP a|{set:cellbgcolor:#FFFFFF} Suppress the (bus) error on an illegal write access caught by the entry * 0x0: respond an error if *ERR_CFG.rs* is 0x0. * 0x1: do not respond an error. User to define the behavior, e.g., respond a success if response is needed -|{set:cellbgcolor:#FFFFFF}sexe |10:10 |WARL |0 a| Suppress the (bus) error on an illegal instruction fetch caught by the entry +|{set:cellbgcolor:#FFFFFF}sexe |10:10 |WARL |IMP a| Suppress the (bus) error on an illegal instruction fetch caught by the entry * 0x0: respond an error if *ERR_CFG.rs* is 0x0. * 0x1: do not respond an error. User to define the behavior, e.g., respond a success with an implementation-dependent value to the initiator. From d0513383e8fa4a0b164d25522c906a545acc29d0 Mon Sep 17 00:00:00 2001 From: tyshyu <172017981+tyshyu@users.noreply.github.com> Date: Fri, 3 Jan 2025 18:20:06 +0800 Subject: [PATCH 3/3] Fix typo and remove repeated description Signed-off-by: tyshyu <172017981+tyshyu@users.noreply.github.com> --- chapter2.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/chapter2.adoc b/chapter2.adoc index 56890c4..cde30f0 100644 --- a/chapter2.adoc +++ b/chapter2.adoc @@ -6,7 +6,6 @@ This document refers to the term “secure monitor” as the software responsibl .Glossary and Acronyms [cols="<1,<3",stripes=even] |=== -2+h|Glossary/ Acronyms{set:cellbgcolor:#D3D3D3} h|Term h|Description |{set:cellbgcolor:#FFFFFF}DC| don't care |IMP|implementation-dependent @@ -138,7 +137,7 @@ Entries indexed by _i_~0~, _i_~1~, …​, _i~N~_ match all bytes of the illegal The error capture record maintains the specifics of the first illegal access detected, except if the following two conditions are held: (1) any interrupt-suppress bit regarding the access is set, and (2) no bus error is returned. New error capture only occurs when there is no currently pending error, namely *ERR_INFO.v* is ‘0’. If a pending error exists (*v* is ‘1’), the record will not be updated, even if a new illegal access is detected. In other words, *v* indicates whether the content of the capture record is valid and should be intentionally cleared in order to capture subsequent illegal accesses. One can write 1 to the bit to clear it. The error capture record is optional. If it is not implemented, *v* should be wired to zero. One can implement the error capture record but not *ERR_REQID.eid*. In this case, *eid* should be wired to 0xffff. -If a transaction violates IOPMP rules on multiple non-priority entries which don't suppress interrupt or bus error respose, the *ERR_REQID.eid* should be one of the entries. +If a transaction violates IOPMP rules on multiple non-priority entries which don't suppress interrupt or bus error response, the *ERR_REQID.eid* should be one of the entries. The following table shows (1) the error types, and (2) related control bits about interrupt triggering and bus error response if the IOPMP supports local control bits (*HWCFG0.peis* is 1 and/or *HWCFG0.pees* is 1):