acs

ACS defines a set of control points within a PCI Express topology to determine whether a TLP is to be routed normally, blocked, or redirected. ACS is applicable to RCs, Switches, and Multi-Function Devices. ¹²⁰ For ACS requirements, single-Function devices that are SR-IOV capable must be handled as if they were Multi-Function Devices, since they essentially behave as Multi-Function Devices after their Virtual Functions (VFs) are enabled.

ACS 在 PCI Express 拓扑中定义了一组控制点，以确定 TLP 是正常路由、阻止还是 重定向。ACS 适用于 RC、交换机和多功能设备。对于 ACS 要求，具有 SR-IOV 功能的 单功能设备必须像多功能设备一样处理，因为在启用虚拟功能 (VF) 后，它们本质上表 现为多功能设备。

Implementation of ACS in RCiEPs is permitted but not required. It is explicitly permitted that, within a single Root Complex, some RCiEPs implement ACS and some do not. It is strongly recommended that Root Complex implementations ensure that all accesses originating from RCiEPs (PFs and VFs) without ACS capability are first subjected to processing by the Translation Agent (TA) in the Root Complex before further decoding and processing. The details of such Root Complex handling are outside the scope of this specification.

RCiEPs: Root Complex Integrated Endpoint

在 RCiEPs 中实施 ACS 是允许的，但不是必需的。明确允许在单个根复合体中，有些 RCiEPs 实现 ACS，而有些则不实现。强烈建议根复合体实现确保所有来自没有 ACS 功能的 RCiEPs （PFs 和 VFs）的访问首先经过Root Complex 中的翻译代理（TA）的处理，然后再进行进一步 的解码和处理。此类根复合体处理的详细信息超出了本规范的范围。

ACS provides the following types of access control:

• ACS Source Validation
• ACS Translation Blocking
• ACS P2P Request Redirect
• ACS P2P Completion Redirect
• ACS Upstream Forwarding
• ACS P2P Egress Control
• ACS Direct Translated P2P
• ACS I/O Request Blocking
• ACS DSP Memory Target Access
• ACS USP Memory Target Access
• ACS Unclaimed Request Redirect

The specific requirements for each of these are discussed in the following section.

ACS hardware functionality is disabled by default, and is enabled only by ACS-aware software. With the exception of ACS Source Validation, ACS access controls are not applicable to Multicast TLPs (see § Section 6.14 ), and have no effect on them.

ACS 硬件功能默认禁用，只能通过支持 ACS 的软件启用。除 ACS Source Validation， ACS access control 不适用于 Multicast TLP（参见第 6.14 节），并且对其没有影响。

6.12.1 ACS Component Capability Requirements

ACS functionality is reported and managed via ACS Extended Capability structures. PCI Express components are permitted to implement ACS Extended Capability structures in some, none, or all of their applicable Functions. The extent of what is implemented is communicated through capability bits in each ACS Extended Capability structure. A given Function with an ACS Extended Capability structure may be required or forbidden to implement certain capabilities, depending upon the specific type of the Function and whether it is part of a Multi-Function Device.

extent: 程度,幅度,范围

ACS 功能通过 ACS 扩展功能结构进行报告和管理。PCI Express 组件可以在部分、全部或 不部分适用功能中实现 ACS 扩展功能结构。实现的范围通过每个 ACS 扩展功能结构中的 功能位进行传达。具有 ACS 扩展功能结构的给定功能可能需要或禁止实现某些功能， 具体取决于功能的具体类型以及它是否是多功能设备的一部分。

ACS is never applicable to a PCI Express to PCI Bridge Function or a Root Complex Event Collector Function, and such Functions must never implement an ACS Extended Capability structure.

不适用 PCIE to PCI bridge Function / Root Complex Event Collector Function.

6.12.1.1 ACS Downstream Ports

This section applies to Root Ports and Switch Downstream Ports that implement an ACS Extended Capability structure. This section applies to Downstream Port Functions both for single-Function devices and Multi-Function Devices.

本节适用于实现 ACS 扩展功能结构的Root Port 和Swith Downstream port。本节适 用于单功能设备和多功能设备的下游端口功能。

• ACS Source Validation: must be implemented.

  When enabled, the Downstream Port tests the Bus Number from the Requester ID of each Upstream Request received by the Port to determine if it is associated with the Secondary side of the virtual bridge associated with the Downstream Port, by either or both of:

  下游端口会检查每个上游请求的请求者 ID 中的总线编号，以确定它是否与与下游端口 相关的虚拟桥的 Secondary side 相关联，可以通过以下一种或两种方式进行判断：

  • Determining that the Requester ID falls within the Bus Number “aperture” of the Port - the inclusive range specified by the Secondary Bus Number register and the Subordinate Bus Number register.

    aperture: 光圈
    falls within: 落在
    

    确定请求者 ID 是否落在端口的总线编号“孔径”内 - 由Subordinate总线编号寄存器 和 Secondary 总线编号寄存器指定的包含范围。

  • If FPB is implemented and enabled, determining that the Requester ID is associated with the bridge’s Secondary Side by the application of the FPB Routing ID mechanism.

    如果实现并启用了 FPB，则通过应用 FPB 路由 ID 机制确定请求者 ID 与桥的 次级侧相关联。

    If the Bus Number from the Requester ID of the Request is not within this aperture, this is a reported error (ACS Violation) associated with the Receiving Port (see § Section 6.12.5 .)

    如果请求中请求者 ID 的总线号不在此范围内，则这是与接收端口相关的已报告错误 （ACS 违规），详见第 6.12.5 节。

    Completions are never affected by ACS Source Validation.

IMPLEMENTATION NOTE:
UPSTREAM MESSAGES AND ACS SOURCE VALIDATION

Functions are permitted to transmit Upstream Messages before they have been assigned a Bus Number. Such messages will have a Requester ID with a Bus Number of 00h. If the Downstream Port has ACS Source Validation enabled, these Messages (see § Table F-1, § Section 2.2.8.2 , and § Section 6.22.1 ) will likely be detected as an ACS Violation error.

在未分配总线号之前，Function 允许发送Upstream消息。此类消息将具有一个总线号为 00h 的请求者 ID。如果下行端口启用了 ACS 源验证，则这些消息（参见表 F-1、第 2.2.8.2 节和第 6.22.1 节）可能会被检测为 ACS 违规错误。

• ACS Translation Blocking: must be implemented.

  When enabled, the Downstream Port checks the Address Type (AT) field of each Upstream Memory Request received by the Port. If the AT field is not the default value, this is a reported error (ACS Violation) associated with the Receiving Port (see § Section 6.12.5 ). This error must take precedence over ACS Upstream Forwarding and any applicable ACS P2P control mechanisms. Completions are never affected by ACS Translation Blocking.

  启用时，下行端口会检查其接收到的每个上行内存请求的地址类型（AT）字段。 如果 AT 字段不是默认值，则这是与接收端口相关的已报告错误（ACS 违规，参见第 6.12.5 节）。此错误必须优先于 ACS 上行转发和任何适用的 ACS P2P 控制机制。 Completions 不会受到 ACS 翻译阻止的影响。

• ACS P2P Request Redirect: must be implemented by Root Ports that support peer-to-peer traffic with other Root Ports; ¹²¹ must be implemented by Switch Downstream Ports.

  ACS P2P 请求重定向：支持与其他根端口进行点对点通信的根端口必须实现该功能； 必须由 Swith 下游端口实现。

  ACS P2P Request Redirect is subject to interaction with the ACS P2P Egress Control and ACS Direct Translated P2P mechanisms (if implemented). Refer to § Section 6.12.3 for more information.

  ACS P2P 请求重定向受 ACS P2P 出口控制和 ACS 直接翻译 P2P 机制（如果已实现）的影响。 有关更多信息，请参阅第 6.12.3 节。

  When ACS P2P Request Redirect is enabled in a Switch Downstream Port, peer-to-peer Requests must be redirected Upstream towards the RC.

  当在交换机下游端口启用 ACS P2P 请求重定向时，点对点请求必须向上游重 定向到根复合体（RC）。

  When ACS P2P Request Redirect is enabled in a Root Port, peer-to-peer Requests must be sent to Redirected Request Validation logic within the RC that determines whether the Request is “reflected” back Downstream towards its original target, or blocked as an ACS Violation error. The algorithms and specific controls for making this determination are not architected by this specification.

  当在根端口启用 ACS P2P 请求重定向时，点对点请求必须发送到根复合体（RC）中的 Redirected Request logic，该逻辑确定请求是“反射”回下游以返回其原始目标，还是作为 ACS 违规错误被阻止。本规范并未设计用于作出此决定的算法和具体控制。

  Downstream Ports never redirect Requests that are traveling Downstream.

  travel: 旅行
  

  下游端口绝不重定向向下游发送的请求。

  Completions are never affected by ACS P2P Request Redirect.

• ACS P2P Completion Redirect: must be implemented by Root Ports that implement ACS P2P Request Redirect; must be implemented by Switch Downstream Ports.

  The intent of ACS P2P Completion Redirect is to avoid ordering rule violations between Completions and Requests when Requests are redirected. Refer to § Section 6.12.6 for more information.

  ACS P2P Completion Redirect does not interact with ACS controls that govern Requests.

  When ACS P2P Completion Redirect is enabled in a Switch Downstream Port, peer-to-peer Completions 122 that do not have the Relaxed Ordering Attribute bit set (1b) must be redirected Upstream towards the RC. Otherwise, peer-to-peer Completions must be routed normally.

  When ACS P2P Completion Redirect is enabled in a Root Port, peer-to-peer Completions that do not have the Relaxed Ordering bit set must be handled such that they do not pass Requests that are sent to Redirected Request Validation logic within the RC. Such Completions must eventually be sent Downstream towards their original peer-to-peer targets, without incurring additional ACS access control checks.

  Downstream Ports never redirect Completions that are traveling Downstream.

  Requests are never affected by ACS P2P Completion Redirect.

• ACS Upstream Forwarding: must be implemented by Root Ports if the RC supports Redirected Request Validation; must be implemented by Switch Downstream Ports.

  When ACS Upstream Forwarding is enabled in a Switch Downstream Port, and its Ingress Port receives an Upstream Request or Completion TLP targeting the Port’s own Egress Port, the Port must instead forward the TLP Upstream towards the RC.

  When ACS Upstream Forwarding is enabled in a Root Port, and its Ingress Port receives an Upstream Request or Completion TLP that targets the Port’s own Egress Port, the Port must handle the TLP as follows. For a Request, the Root Port must handle it the same as a Request that the Port “redirects” with the ACS P2P Request Redirect mechanism. For a Completion, the Root Port must handle it the same as a Completion that the Port “redirects” with the ACS P2P Completion Redirect mechanism.

  When ACS Upstream Forwarding is not enabled on a Downstream Port, and its Ingress Port receives an Upstream Request or Completion TLP that targets the Port’s own Egress Port, the handling of the TLP is undefined.

• ACS P2P Egress Control: implementation is optional.

  ACS P2P Egress Control is subject to interaction with the ACS P2P Request Redirect and ACS Direct Translated P2P mechanisms (if implemented). Refer to § Section 6.12.3 for more information.

  A Switch that supports ACS P2P Egress Control can be selectively configured to block peer-to-peer Requests between its Downstream Ports. Software can configure the Switch to allow none or only a subset of its Downstream Ports to send peer-to-peer Requests to other Downstream Ports. This is configured on a per Downstream Port basis.

  An RC that supports ACS P2P Egress Control can be selectively configured to block peer-to-peer Requests between its Root Ports. Software can configure the RC to allow none or only a subset of the Hierarchy Domains to send peer-to-peer Requests to other Hierarchy Domains. This is configured on a per Root Port basis.

  With ACS P2P Egress Control in Downstream Ports, controls in the Ingress Port (“sending” Port) determine if the peer-to-peer Request is blocked, and if so, the Ingress Port handles the ACS Violation error per § Section 6.12.5 .

  Completions are never affected by ACS P2P Egress Control.

• ACS Direct Translated P2P: must be implemented by Root Ports that support Address Translation Services (ATS) and also support peer-to-peer traffic with other Root Ports; 123 must be implemented by Switch Downstream Ports.

  When ACS Direct Translated P2P is enabled in a Downstream Port, peer-to-peer Memory Requests whose Address Type (AT) field indicates a Translated address must be routed normally (“directly”) to the peer Egress Port, regardless of ACS P2P Request Redirect and ACS P2P Egress Control settings. All other peer-to-peer Requests must still be subject to ACS P2P Request Redirect and ACS P2P Egress Control settings.

  Completions are never affected by ACS Direct Translated P2P.

• ACS I/O Request Blocking: must be implemented by Root Ports and Switch Downstream Ports that support ACS Enhanced Capability.

  When enabled, the Port must handle an Upstream I/O Request received by the Port’s Ingress as an ACS Violation.

• ACS DSP Memory Target Access: must be implemented by Root Ports and Switch Downstream Ports that support ACS Enhanced Capability and that have applicable Memory BAR Space to protect.

  ACS DSP Memory Target Access determines how an Upstream Request received by the Downstream Port’s Ingress and targeting any Memory BAR Space 124 associated with an applicable Downstream Port is handled. The Request can be blocked, redirected, or allowed to proceed directly to its target. In a Switch, all Downstream Ports are applicable, including the one on which the Request was received. In a Root Complex, the set of applicable Root Ports is implementation specific, but always includes the one on which the Request was received.

• ACS USP Memory Target Access: must be implemented by Switch Downstream Ports that support ACS Enhanced Capability and that have applicable Memory BAR Space in the Switch Upstream Port to protect; is not applicable to Root Ports.

  ACS USP Memory Target Access determines how an Upstream Request received by the Switch Downstream Port’s Ingress and targeting any Memory BAR Space 125 associated with the Switch’s Upstream Port is handled. The Request can be blocked, redirected, or allowed to proceed directly to its target.

  If any Functions other than the Switch Upstream Port are associated with the Upstream Port, this field has no effect on accesses to their Memory BAR Space 126 . Such access is controlled by the ACS Extended Capability (if present) in the Switch Upstream Port.

• ACS Unclaimed Request Redirect: must be implemented by Switch Downstream Ports that support ACS Enhanced Capability; is not applicable to Root Ports.

  When enabled, incoming Requests received by the Switch Downstream Port’s Ingress and targeting Memory Space within the memory window of a Switch Upstream Port that is not within a memory window or Memory BAR Target of any Downstream Port within the Switch are redirected Upstream out of the Switch.

  When not enabled, such Requests are handled by the Switch Downstream Port as an Unsupported Request (UR).

6.12.1.2 ACS Functions in SR-IOV Capable and Multi-Function Devices

This section applies to Multi-Function Device ACS Functions, with the exception of Downstream Port Functions, which are covered in the preceding section. For ACS requirements, single-Function devices that are SR-IOV capable must be handled as if they were Multi-Function Devices.

• ACS Source Validation: must not be implemented.
• ACS Translation Blocking: must not be implemented.

• ACS P2P Request Redirect: must be implemented by Functions that support peer-to-peer traffic with other Functions. This includes SR-IOV Virtual Functions (VFs).

  ACS P2P Request Redirect is subject to interaction with the ACS P2P Egress Control and ACS Direct Translated P2P mechanisms (if implemented). Refer to § Section 6.12.3 for more information.

  When ACS P2P Request Redirect is enabled in a Multi-Function Device that is not an RCiEP, peer-to-peer Requests (between Functions of the device) must be redirected Upstream towards the RC.

  It is permitted but not required to implement ACS P2P Request Redirect in an RCiEP. When ACS P2P Request Redirect is enabled in an RCiEP, peer-to-peer Requests, defined as all Requests that do not target system memory, must be sent to implementation specific logic within the Root Complex that determines whether the Request is directed towards its original target, or blocked as an ACS Violation error. The algorithms and specific controls for making this determination are not architected by this specification.

  Completions are never affected by ACS P2P Request Redirect.

  ACS P2P Completion Redirect: must be implemented by Functions that implement ACS P2P Request Redirect. The intent of ACS P2P Completion Redirect is to avoid ordering rule violations between Completions and Requests when Requests are redirected. Refer to § Section 6.12.6 for more information.

  ACS P2P Completion Redirect does not interact with ACS controls that govern Requests.

  When ACS P2P Completion Redirect is enabled in a Multi-Function Device that is not an RCiEP, peer-to-peer Completions that do not have the Relaxed Ordering bit set must be redirected Upstream towards the RC. Otherwise, peer-to-peer Completions must be routed normally.

  Requests are never affected by ACS P2P Completion Redirect.

• ACS Upstream Forwarding: must not be implemented.

• ACS P2P Egress Control: implementation is optional; is based on Function Numbers or Function Group Numbers; controls peer-to-peer Requests between the different Functions within the multi-Function or SR-IOV capable device.

  ACS P2P Egress Control is subject to interaction with the ACS P2P Request Redirect and ACS Direct Translated P2P mechanisms (if implemented). Refer to § Section 6.12.3 for more information.

  Each Function within a Multi-Function Device that supports ACS P2P Egress Control can be selectively enabled to block peer-to-peer communication with other Functions or Function Groups 127 within the device. This is configured on a per Function basis.

  With ACS P2P Egress Control in multi-Function or SR-IOV capable devices, controls in the “sending” Function determine if the Request is blocked, and if so, the “sending” Function handles the ACS Violation error per § Section 6.12.5 .

  When ACS Function Groups are enabled in an ARI Device (ACS Function Groups Enable is Set), ACS P2P Egress Controls are enforced on a per Function Group basis instead of a per Function basis. See § Section 6.13 .

  Completions are never affected by ACS P2P Egress Control.

• ACS Direct Translated P2P: must be implemented if the Multi-Function Device Function supports Address Translation Services (ATS) and also peer-to-peer traffic with other Functions.

  When ACS Direct Translated P2P is enabled in a Multi-Function Device, peer-to-peer Memory Requests whose Address Type (AT) field indicates a Translated address must be routed normally (“directly”) to the peer Function, regardless of ACS P2P Request Redirect and ACS P2P Egress Control settings. All other peer-to-peer Requests must still be subject to ACS P2P Request Redirect and ACS P2P Egress Control settings.

  Completions are never affected by ACS Direct Translated P2P.

6.12.1.3 Functions in Single-Function Devices

This section applies to single-Function device Functions, with the exception of Downstream Port Functions and SR-IOV capable Functions, which are covered in a preceding section. For ACS requirements, single-Function devices that are SR-IOV capable must be handled as if they were Multi-Function Devices.

No ACS capabilities are applicable, and the Function must not implement an ACS Extended Capability structure.