iopmp-1.0.0-draft4

appendix_a1.adoc

@@ -1,4 +1,4 @@
 [Appendix_A1]
-== A1: Reference Data Path
+== A1: Multi-Faults Extension
 
 TBD

appendix_a2.adoc

@@ -1,4 +1,22 @@
 [Appendix_A2]
-== A2: Cascading IOPMPs
+== A2: Run Out Memory Domains
+In this specification, the support is capped at 63 memory domains. However, this chapter provides pertinent recommendations for situations that necessitate a larger number of memory domains.
 
-TBD
+*A2.1 Parallel IOPMP*
+
+Multiple IOPMPs can be placed in parallel. A transaction should be directed to one of these IOPMPs for its check. The chosen IOPMP then determines its legality. There are two potential methods for routing the transaction: by address or by SID. Address-based routing divides the address space into multiple disjoint sets, and a transaction is directed to the IOPMP based on its starting address. Similarly, SID-based routing divides all possible SIDs, and a transaction is directed to the IOPMP based on its SID.
+
+[NOTE]
+====
+Placing IOPMPs in parallel can seamlessly enhance the support for an increased number of memory domains since all the IOPMPs are located in the same position. This arrangement may also concurrently increase the checking throughput.
+====
+
+*A2.2 Cascading IOPMP*
+
+Cascading multiple IOPMPs allows a transaction to traverse through more than one IOPMP. Each time a transaction goes through an IOPMP, it is tagged a new SID until it reaches the final IOPMP. This new SID represents that the transaction has been checked by a specific IOPMP. Subsequent IOPMPs could deem the transaction trustworthy and forward it to their initiator port without further checks, or check it in a higher level view, e.g., a subsystem view. An IOPMP with the above feature of tagging a new SID is referred to as an IOPMP gateway. Its HWCFG0.sid_transl_en should be set to 1, and HWCFG2.sid_transl is used to store the SID.  HWCFG0.sid_transl_prog indicates whether HWCFG2.sid_transl is programmable or not. To lock sid_transl, write 1 to sid_transl_prog, which cleans sid_transl_prog and is sticky to 0.
+
+[NOTE]
+====
+The integration of several independently developed smaller Systems on a Chip (SoCs) to construct a larger SoC reduces the chip count in a device. This approach also decreases costs by enabling the use of larger and shared memory devices. In such a system, each subsystem upholds its governance through its own secure software, SID assignment, and security configuration. The cascading approach facilitates this: the secure software manages the IOPMP in the boundary of the subsystem. The boundary IOPMP assigns a new SID to each outgoing transaction, representing that it has been checked by the IOPMP. 
+The outer IOPMPs are tasked with controlling the transactions from a subsystem perspective by the new subsystem-level SID. That is, the IOPMP only considers the legality of the transactions initiated from a specific subsystem instead of individual transaction initiators. The boundary IOPMP hides some details of the subsystem good for protecting intellect properties. The development flow becomes more abstract, reusable, and modularized.
+====

appendix_a3.adoc

@@ -1,12 +1,11 @@
 [Appendix_A3]
-== A3: Permission on Memory Domains
+== A3: Sencondary Permission Setting
 
-In the models mentioned so far, an IOPMP entry is a pair of a memory region and its corresponding permission setting. The bits used to store the memory region are much more than its permission setting. If different memory domains want to share these regions but not their permission settings, the IOPMP/PMD described in this appendix can help.
+IOPMP/SPS is an extension to support different sources to share memory domain while allowing each sources to have different R/W/X permission to a single memory domain.
 
-IOPMP/PMD extends every association bit in the SRCMD table to 4 bits of a second permission setting. We denote SPS[_s_, _m_] as the second permission setting for SID=_s_ and MID=_m_. When a transaction arrives at an IOPMP/PMD, it looks up the corresponding memory domains as usual. Then, it also follows the original way to find the IOPMP entry matching the transaction. When checking the permission, IOPMP/PMD has two sets of permission settings: one from IOPMP entry and the other from the second permission setting that is retrieved from SPS. For either read or write operation, only if both permission settings allow, the transaction can do such operation.
+If the IOPMP/SPS extension is implemented, each SRCMD table entry shall additionally define two registers: SRCMD_R(_s_) and SRCMD_R(_s_). Register SRCMD_R(_s_) and SRCMD_R(_s_) each occupies a 64-bit space, and has a fields, SRCMD_R(_s_).md and SRCMD_W(_s_).md respectively. Setting lock to SRCMD_EN(_s_).l also locks SRCMD_R(_s_) and SRCMD_W(_s_). 
 
-Besides, SPS can offer the control of execution permission. If the signal indicating an instruction fetch is carried by a transaction, the second permission setting can control instruction fetches.
+IOPMP/SPS has two sets of permission settings: one from IOPMP entry and the other from SRCMD_R/SRCMD_W. IOPMP/SPS shall check read and write permission on both the SRCMD table and entries, a transaction fail the IOPMP/SPS check if it violates either of the permission settings.
 
-As the programmability of every second permission setting, it is the same as the programmability of the bit in the same location in the SRCMD table.
+Besides, IOPMP/SPS can offer the control of execution permission. If the signal indicating an instruction fetch is carried by a transaction, the second permission setting can control instruction fetches.
 
-SPS also supports up to 63 memory domains. The LSB of SPS[_s_, 63] is reserved for locking all second permission settings for SID = _s_.