Merge pull request #15 from vlsunil/arc_feedback

Address ARC feedback for RC3

Makefile

@@ -13,7 +13,7 @@
 # the Doc Template for RISC-V Extensions.
 
 DATE ?= $(shell date +%Y-%m-%d)
-VERSION ?= v1.0.0-rc3
+VERSION ?= v1.0.0-rc4
 REVMARK ?= Draft
 DOCKER_RUN := docker run --rm -v ${PWD}:/build -w /build \
 riscvintl/riscv-docs-base-container-image:latest

src/changelog.adoc

@@ -1,13 +1,17 @@
 == Changelog
 
+- *Version 1.0.0-rc4*
+  * Added source ID overlap restriction details.
+  * Addressed other ARC feedback for RC3 version.
+
 - *Version 1.0.0-rc3*
   * Addressed feedback from ARC review.
 
 - *Version 1.0.0-rc2*
   * Draft for ARC review.
   * Addressed internal review feedback.
   * Used IEEE style bibliography.
-  * Allowed HW ID to be valid for PCI IOMMU as well.
+  * Allowed HW ID to be valid for PCIe IOMMU as well.
 
 - *Version 1.0.0-rc1*
   * Draft for internal review.

src/intro.adoc

@@ -4,4 +4,4 @@ The RISC-V IO Mapping Table (RIMT)  provides information about the RISC-V IOMMU
 cite:[IOMMU-SPEC] and the relationship between the IO topology and the IOMMU in
 ACPI cite:[ACPI-SPEC] based RISC-V platforms. The RIMT identifies which
 components are behind IOMMU and how they are connected together. RISC-V IOMMU
-can be implemented as either a PCI device or a platform device.
+can be implemented as either a PCIe device or a platform device.

src/rimt-main.adoc

@@ -41,7 +41,7 @@ device.
 === RIMT node structure types
 RIMT node structures can be broadly classified as two types: one is the actual IOMMU node
 structure and the other is the device node structure for devices bound to an IOMMU. The device node
-structure can be further classified as PCIe and platform device structures bound to an IOMMU. For example,
+structure can be further classified as PCIe root complex and platform device structures bound to an IOMMU. For example,
 in a system with a single IOMMU, RIMT should have at least two nodes. One for the IOMMU itself
 and another for the devices behind this particular IOMMU. <<rimt_node_structure>> lists possible
 types for those structures.
@@ -203,14 +203,22 @@ a|
 							    See <<id_mapping_structure>>.
 |===
 
-The ID mapping structure provides information on how devices are connected to an IOMMU. The devices
-may be natively identified by a source ID but the platform may use a remapped ID to identify
-transactions from the device to the IOMMU. For PCI devices, source ID is the 16-bit triplet of PCI
-bus number (8-bit), device number (5-bit), and function number (3-bit) (collectively known as routing
-identifier or RID). For platform devices, it is the implementation specific ID and managed
-by the device driver. Each ID mapping array entry provides a mapping from a
-range of source IDs to the corresponding device IDs that will be used at the input to the IOMMU.
-See <<Mapping-Examples>> for an example of ID mapping structures.
+The ID mapping structure provides information on how devices are connected to an IOMMU. The devices may be
+natively identified by a source ID but the platform may use a remapped ID to identify transactions from the
+device to the IOMMU.
+
+For PCIe devices, source ID is the 16-bit triplet of PCIe bus number (8-bit), device number (5-bit), and
+function number (3-bit) (collectively known as routing identifier or RID). A range of source IDs must map to a
+single IOMMU only. If there are multiple root complexes with the same PCIe segment number, then their source
+ID ranges must not overlap. For each ACPI device object of the root complex which belongs to the same PCIe
+segment, the firmware must include the Device Specific Method (_DSM), Function Index 5, for preserving boot
+configurations as defined by the PCI Firmware Specification cite:[PCI-FW-SPEC]. The _DSM method must return
+zero to indicate that the Operating System must preserve PCIe resource assignments made by the firmware at
+boot time.
+
+For platform devices, it is the implementation specific ID and managed by the device driver. Each ID mapping
+array entry provides a mapping from a range of source IDs to the corresponding device IDs that will be used at
+the input to the IOMMU. See <<Mapping-Examples>> for an example of ID mapping structures.
 
 .ID Mapping Structure
 [[id_mapping_structure]]
@@ -233,7 +241,7 @@ See <<Mapping-Examples>> for an example of ID mapping structures.
 | Destination IOMMU Offset   | 4             | 12            | The destination IOMMU with which the
                                                                these IDs are associated. This field
                                                                is the offset of the RISC-V IOMMU
-                                                               node to the start of the RIMT
+                                                               node from the start of the RIMT
                                                                table.
 | Flags                      | 4             | 16
 a|

src/rimt.bib

@@ -1,8 +1,12 @@
+@electronic{ACPI-SPEC,
+  title = {Advanced Configuration and Power Interface Specification 6.5},
+  url = {https://uefi.org/specs/ACPI/6.5}
+}
 @electronic{IOMMU-SPEC,
   title = {RISC-V IOMMU Specification 1.0.0},
   url = {https://github.com/riscv-non-isa/riscv-iommu/releases/download/v1.0.0/riscv-iommu.pdf}
 }
-@electronic{ACPI-SPEC,
-  title = {Advanced Configuration and Power Interface Specification 6.5},
-  url = {https://uefi.org/specs/ACPI/6.5}
+@electronic{PCI-FW-SPEC,
+  title = {PCI Firmware Specification 3.3},
+  url = {https://members.pcisig.com/wg/PCI-SIG/document/folder/862}
 }

src/terms.adoc

@@ -7,8 +7,8 @@ This specification uses the following terms and abbreviations:
 | Term  | Meaning
 
 | ACPI  | Advanced Configuration and Power Interface Specification
+| APLIC | Advanced Platform-Level Interrupt Controller
 | IOMMU | Input-Output Memory Management Unit
-| RCiEP | Root Complex Integrated End Point
 | PLIC  | Platform-Level Interrupt Controller
-| APLIC | Advanced Platform-Level Interrupt Controller
+| RCiEP | Root Complex Integrated End Point
 |===