Merge pull request #40 from ved-rivos/edit_0329

Editorial updates + add IOM_300 and IOM_310 functional requirements

src/server_soc_contributors.adoc

@@ -3,4 +3,4 @@
 This RISC-V specification has been contributed to directly or indirectly by (in alphabetical order):
 
 [%hardbreaks]
-Aaron Durbin, Andrei Warkentin, Andrew Jones, Beeman Strong, Cameron McNairy, Greg Favor, Heinrich Schuchardt, Isaac Chute, Jon Masters, Ken Dockser, Krste Asanovic, Manu Gulati, Mark Hayter, Michael Klinglesmith, Paul Walmsley, Shaolin Xie, Shubu Mukherjee, Sibaranjan Pattnayak, Ved Shanbhogue
+Aaron Durbin, Andrea Bolognani, Andrei Warkentin, Andrew Jones, Beeman Strong, Cameron McNairy, Greg Favor, Heinrich Schuchardt, Isaac Chute, Jon Masters, Ken Dockser, Krste Asanovic, Manu Gulati, Mark Hayter, Michael Klinglesmith, Paul Walmsley, Ravi Sahita, Shaolin Xie, Shubu Mukherjee, Sibaranjan Pattnayak, Ved Shanbhogue

src/server_soc_requirements.adoc

@@ -248,19 +248,35 @@ deliver external interrupts to the RISC-V application processor harts.
      requester across PCIe hierarchies._
 
 | IOM_270  | The host bridge MUST provide the PCIe RID as the bits 15:0 of the
-             device_id to the IOMMU for requests from PCIe EPs and RCiEP.
+             `device_id` input to the IOMMU for requests from PCIe EPs and
+             RCiEP.
 
 | IOM_280  | When the IOMMU supports 24-bit device IDs, the host bridge MUST
              specify the segment number associated with the PCIe hierarchy from
-             which requests were received as the bits 23:16 of the device_id to
-             the IOMMU.
+             which requests were received as the bits 23:16 of the `device_id`
+             to the IOMMU.
 
-| IOM_290  | The determination of device_id input to an IOMMU for requests
+| IOM_290  | The determination of `device_id` input to an IOMMU for requests
              originating from non-PCIe devices is `UNSPECIFIED`. If PCIe and
              non-PCIe endpoints/RCiEP are governed by the same IOMMU, the SoC
-             MUST ensure that there is no overlap between any device_id
-             associated with non-PCIe devices with any device_id formed using
+             MUST ensure that there is no overlap between any `device_id`
+             associated with non-PCIe devices with any `device_id` formed using
              the PCIe RID (and if applicable the segment ID).
+
+| IOM_300  | The host bridge MUST provide the 20-bit PASID from the PCIe PASID
+             TLP Prefix as the `process_id` input to the IOMMU along with an
+             indication about the validity of the `process_id` input. When the
+             `process_id` is indicated as valid, the host bridge MUST
+             additionally provide the "Execute Requested" and the "Privilege
+             Mode Requested" bits from the PASID TLP prefix as input to the
+             IOMMU. When `process_id` input is indicated as not valid the host
+             bridge MUST set the "Execute Requested" and "Privilege Mode
+             Requested" inputs as 0.
+
+| IOM_310  | The determination of `process_id`, "Execute Requested", and
+             "Privilege Mode Requested" inputs to an IOMMU for requests
+             originating from non-PCIe devices is `UNSPECIFIED`.
+
 |===
 
 === PCIe Subsystem
@@ -394,15 +410,15 @@ hierarchy domain originating at each PCIe root port.
              responded with all 1s data if any of the following conditions are
              TRUE:
 
-            * Access is to non-existent functions on the primary bus of a
+            * Access is to a non-existent function on the primary bus of a
               hierarchy domain.
             * Accessed bus is not part of any of the hierarchy domains.
             * An Unsupported Request or Completer Abort response was received.
             * A completion timeout occurs.
             * Access targets a function downstream of a root port whose link
               is not in DL_Active state.
-            * A PCIe RRS response was received and CRS software visibility is
-              not enabled.
+            * A PCIe RRS response was received on each retry of the
+               configuration read and CRS software visibility is not enabled.
             * PCIe CRS software visibility is enabled, but the access does not
               target the vendor ID register, and a RRS response was received on
               each retry of the configuration read.
@@ -411,8 +427,8 @@ hierarchy domain originating at each PCIe root port.
      MUST follow the PCIe defined rules. See also the recommendations in PCIe
      specification 6.0 section 2.3.2._
 
-| ECM_110 | Write access from a RISC-V hart to configuration registers of
-            non-existent functions on the primary bus MUST be dropped (silently
+| ECM_110 | Write access from a RISC-V hart to configuration registers of a
+            non-existent function on the primary bus MUST be dropped (silently
             ignored or discarded) and the write completed. Such accesses MUST
             NOT lead to any other behavior (e.g., hangs, deadlocks, etc.).
 
@@ -445,10 +461,10 @@ hierarchy domain originating at each PCIe root port.
      as high MMIO ranges._
 
 | MMS_030 a| The system physical address ranges designated for mapping endpoint
-             memory spaces have the following physical memory attributes (PMAs)
+             memory spaces have the following physical memory attribute (PMAs)
              requirements:
 
-             * MUST be Not-cacheable, non-idempotent, coherent, strongly-ordered
+             * MUST be not cacheable, non-idempotent, coherent, strongly-ordered
                (I/O ordering) I/O region.
              * MUST support all aligned and unaligned access sizes that can be
                generated by data requests from any of the RISC-V application
@@ -535,7 +551,7 @@ devices, and SR-IOV capable devices.
 |===
 | ID#     ^| Requirement
 | ACS_010 a| PCIe root ports and SoC integrated downstream switch ports MUST
-             support the following PCIe access control services (ACS) controls
+             support the following PCIe access control services (ACS) controls:
 
              * ACS source validation.
              * ACS translation blocking.
@@ -647,7 +663,7 @@ space of an endpoint or RCiEP.
 ==== ID Routed Transactions
 
 The rules in this section apply to treatment in the root complex of TLPs that
-are routed by ID. Such requests may be ID Configuration requests, ID routed
+are routed by ID. Such requests may be Configuration requests, ID routed
 messages or completions.
 
 [width=100%]
@@ -750,9 +766,10 @@ mechanism in PCIe.
 
 | MSI_020  | SoC MUST NOT require any further action from the operating system
              besides configuring the MSI address register in devices with the
-             address of an IMSIC interrupt register file (or a virtual interrupt
-             file) and the MSI data register in devices with an external
-             interrupt identity to enable the use of MSI or MSI-X.
+             address of an IMSIC interrupt file -- a supervisor-level interrupt
+             file or a guest interrupt file -- and the MSI data register in
+             devices with an external interrupt identity to enable the use of
+             MSI or MSI-X.
 
 | MSI_030  | SoC MUST NOT support INTx virtual wire based interrupt signaling.
 2+| _PCIe supports INTx emulation to support legacy PCI interrupt mechanisms.
@@ -876,9 +893,9 @@ mechanism in PCIe.
      participate in RAS frameworks like data poisoning and AER, power management,
      etc._
 
-| SID_020  | SoC-integrated PCIe devices MUST NOT use legacy PCI capabilities.
-             They MUST NOT require the use of I/O space, I/O transactions, or
-             the INTx virtual wire interrupt signaling mechanism.
+| SID_020  | SoC-integrated PCIe devices MUST NOT require the use of I/O space,
+             I/O transactions, or the INTx virtual wire interrupt signaling
+             mechanism.
 
 | SID_030  | SoC integrated PCIe devices that cache address translations MUST
              implement the PCIe ATS capability if the address translation cache
@@ -981,7 +998,7 @@ mechanism in PCIe.
                                                                                +
    _Data poisoning also empowers the implementation of error containment
     features supported by industry standards like PCIe and CXL._               +
-
+                                                                               +
    _For more detailed discussions on the treatment of faults and errors, refer
     to the RISC-V RERI specification._
 
@@ -1002,7 +1019,6 @@ mechanism in PCIe.
 
 | RAS_040  | The SoC SHOULD support the RISC-V RAS error record register
              interface (RERI) cite:[RERI] for error logging and signaling.
-2+| _Note RERI is still under construction._
 
 | RAS_050  | When RERI is supported, the RAS error records MUST include the
              capability to individually enable error signaling for each severity -
@@ -1221,23 +1237,15 @@ data centers and enterprises.
              of counting:
 
              * Cache lookup
-             * Cache miss                                                      +
-                                                                               +
-             If the SoC supports NUMA configurations, then the HPM SHOULD
-             support filtering the counting based on whether the request
-             originated in a local node or a remote node.
+             * Cache miss
 2+| _It is recommended that a cache with a capacity larger than 32 KiB be
      considered a significant cache._
 
 | SPM_020 a| The memory controllers within the SoC SHOULD incorporate an HPM
              capable of counting:
 
              * Read bandwidth
-             * Write bandwidth                                                 +
-                                                                               +
-             If the SoC supports NUMA configurations, then the HPM SHOULD
-             support filtering the counting based on whether the request
-             originated in a local node or a remote node.
+             * Write bandwidth
 
 | SPM_030 a| The PCIe ports within the SoC SHOULD incorporate an HPM capable of
              counting:
@@ -1247,15 +1255,16 @@ data centers and enterprises.
 
 | SPM_040 a| The SoC SHOULD incorporate an HPM capable of counting the average
              latency of a read request from a memory requester (e.g., a hart,
-             a PCIe host bridge, etc.) in the SoC.                             +
-                                                                               +
-             If the SoC supports NUMA configurations, then the HPM SHOULD
-             support filtering the counting based on whether the request is to
-             local memory or to remote memory.
+             a PCIe host bridge, etc.) in the SoC.
 2+| _Bandwidth and latency are the most commonly used performance metrics to
      guide workload placement and tuning._
 
-| SPM_050  | The PCIe Gen6 ports within the SoC SHOULD incorporate support for
+| SPM_050 a| If the SoC supports NUMA configurations, then the HPM for
+             SPM_010, SPM_020, SPM_030, and SPM_040 SHOULD support filtering the
+             counting based on whether the request is to local memory or to
+             remote memory.
+
+| SPM_060  | The PCIe Gen6 ports within the SoC SHOULD incorporate support for
              the Flit performance measurement extended capability defined by
              PCIe specification 6.0.
 |===
@@ -1266,42 +1275,42 @@ data centers and enterprises.
 [%header, cols="5,25"]
 |===
 | ID#     ^| Requirement
-| SEC_005 a| The Server SoC MUST comply with the requirements and guidelines
+| SEC_010 a| The Server SoC MUST comply with the requirements and guidelines
              detailed in Reference Model, Ecosystem Security Objectives, and
              the Cryptography sections of the RISC-V Security Model Version
-             1.0 cite:[SEC].  The Server SoC is classified as a complex
+             1.0 cite:[SEC]. The Server SoC is classified as a complex
              security system for the purposes of SR_ROT_001 and SR_ATT_002.
 
-| SEC_006 a| The Server SoC MUST support the Generic System Without Supervisor
+| SEC_020 a| The Server SoC MUST support the Generic System Without Supervisor
              Domains use case detailed in the RISC-V Security Model Version 1.0.
              The building blocks used to implement this use case MUST comply
              with the requirements specified in the RISC-V Security Building
              Blocks section of the RISC-V Security Model specification.
 
-| SEC_007 a| The Server SoC MAY support the Confidential Computing on RISC-V
-             (CoVE) use detailed in the RISC-V Security Model Version 1.0. The
+| SEC_030 a| The Server SoC MAY support the Confidential Computing on RISC-V
+             (CoVE) use case detailed in the RISC-V Security Model Version 1.0. The
              building blocks used to implement this use case MUST comply with
              the requirements specified in the RISC-V Security Building Blocks
              section of the RISC-V Security Model specification.
 
-| SEC_010  | The PCIe root ports within the SoC SHOULD support PCIe Integrity and
+| SEC_040  | The PCIe root ports within the SoC SHOULD support PCIe Integrity and
              Data Encryption (IDE) capability.
 2+| _The IDE extension adds optional capabilities to perform hardware encryption
      and integrity checks on packets transferred across PCIe links. This addition
      provides confidentiality, integrity, and replay protection against
      hardware-level attacks._
 
-| SEC_020  | The SoC SHOULD support encryption of off-chip DRAM using a
+| SEC_050  | The SoC SHOULD support encryption of off-chip DRAM using a
              transient memory encryption key that has at least 256-bit key
              lengths.
 2+| _Off-chip memory encryption provides protection to critical assets in memory
      such as credentials, data encryption keys, and other secrets._
 
-| SEC_030  | The cryptographic modules used to implement PCIe and off-chip DRAM
+| SEC_060  | The cryptographic modules used to implement PCIe and off-chip DRAM
              encryption SHOULD comply with security requirements specified by
              standards such as FIPS 140-3.
 
-| SEC_040  | The SoC SHOULD have the capability interfacing with a Trusted
+| SEC_040  | The SoC SHOULD have the capability of interfacing with a Trusted
              Platform Module (TPM) that adheres to the TPM 2.0 Library
              specification cite:[TPM20].
 2+| _A TPM enhances security by providing secure storage for sensitive