PCIe Base Specification解析（四）

2.3 Handling of Received TLPs

本节介绍接收到的TLP在数据链路层经过完整性验证之后，这些TLP在事务处理层时的处理方式。这些规则如Figure 2-41所示。

• 接收侧会忽略保留字段。
• 如果Fmt字段显示存在至少一个TLPPrefix：
  • 通过检查后续DWORD的第一个字节中的Fmt字段，直到Fmt字段与TLP Prefix的字段不匹配，来检测header中是否存在其他TLP Prefix。（每个TLP Prefix为一个DWORD长度。）
  • 根据Section 2.2.10的规则来处理TLP Prefix。
• 如果Extended Fmt FieldSupported字段设置为1，则收到的Fmt和Type字段编码为保留值的TLP是Malformed TLP（请参阅Table2-1和Table 2-3）。
• 如果 Extended Fmt Field Supported字段设置为0，则收到的Fmt[2］为1的TLP的处理方式未定义。
• 收到的Fmt[2］为0，且Type字段为保留值的TLP为Malformed TLP。
• 收到的TLP为Malformed TLP，则该TLP被丢弃。
  • 如果接收到的Malformed TLP导致不知道释放哪个缓冲区，也不知道怎么映射到未初始化的虚通道，则必须要丢弃且不更新接收侧的流控制信息。
  • 必须丢弃所有其他类型的Malformed TLP，可以选择不更新接收侧的流控制信息。
• 否则，更新流控制更新逻辑（Section 2.6）。
• 如果Type字段中的值指示TLP是个Request，请按照Section 2.3.1进行处理；否则，收到的TLP是一个Completion，请按照Section 2.3.2进行处理。
  

Figure 2-41 Flowchart for Handling of Received TLPs

Switch 必须能处理寻址Switch 本身资源的TLP与寻址 Switch挂接的设备资源的TLP。Switch根据上述规则处理所有寻址 Switch 本身资源的TLP。根据以下规则处理通过Switch的TLP（请参见 Figure 2-42)：

• 如果收到的TLP的Type字段显示该TLP不是Msg或MsgD请求，则该TLP按照Section 2.2.4.1和Section 2.2.4.2的路由规则进行处理。
• Switch中Completion的路由使用Completion中的Requester ID字段来完成。
• 如果收到的TLP的Type字段显示该TLP是一个Msg或MsgD请求，则该请求的路由规则根据Type子字段r[2:0］来进行。

  • 如果r[2:0］显示Msg/MsgD请求路由到RC(000b),Switch就把它路由到该Switch的Upstream Port。

    • 在Switch的Upstream Port上收到一个r[2:0］为000b的Msg/MsgD请求被认为是一个错误。Switch可能检查是否违反了这个规则-违反该规则的TLP是Malformed TLP。

  • 如果r[2:0］显示Msg/MsgD请求按地址路由（001b),Switch就按Memory请求的规则来路由该Msg/MsgD。

  • 如果r[2:0］显示Msg/MsgD请求按ID路由（010b),Switch就按 Completion的规则来路由Msg/MsgD。

  • 如果r[2:0］显示Msg/MsgD是来自RC的广播路由（011b),Switch 就把它路由到该Switch的所有 Downstream Port。

    • 在Switch的Downstream Port上收到一个r[2:0］为011b的Msg/MsgD请求被认为是一个错误。Switch可能检查是否违反了这个规则–违反该规则的TLP是Malformed TLP。

  • 如果r[2:0］显示Msg/MsgD终结于接收侧（100b或保留值），或者如果Message Code字段值已定义且对应于Switch 必须理解的消息，则Switch必须根据消息处理规则处理该消息。

  • 如果r[2:0］显示Msg/MsgD请求路由到RC(101b）且被收集，参阅Section 5.3.3.2.1节的消息处理规则。

  • 除PME_TO_Ack以外，收到任何r[2:0］为101b的Msg/MsgD请求都被认为是一个错误。在Switch的Upstream Port上收到一个PME_TO_Ack是个错误。Switch可以选择检查是否违反了这些规则（参阅Section 6.2.3.4）。如果要做检查，则违反该规则的TLP是Malformed TLP。

Figure 2-42 Flowchart for Switch Handling of TLPs

2.3.1 Request Handling Rules

本节介绍如何处理接收到的Request。这些规则如Figure 2-43所示。

• 如果Request的类型是设备不支持的（因为设计或配置的原因），则该请求被处理为Unsupported
  Request，这会根据Section 6.2的描述来报告。
  • 如果该请求需要返回Completion，则返回一个Completion Status字段为UR的Completion (see Section 2.2.9）。

IMPLEMENTATION NOTE

When Requests are Terminated Using Unsupported Request

在传统的PCI中，设备通过声明DEVSEL＃在总线上“声明”请求。如果没有设备在设置的时钟数后发出一个请求，则该请求将作为一个Master Abort而终止。由于PCI Express是点对点互连，它没有等效的机制可以在链路上声明请求，因此一个组件的所有传输总是发送到链路上的另一个组件。因此，请求的接收者有必要确定是否应“声明”该请求。如果未声明该请求，则将其作为Unsupported Request 处理，这种处理方式使得PCI Express与传统的PCI的Master Abort终结等效。通常，可以通过提出以下问题来确定正确的行为：Would the device assert DEVSEL# for this request in conventional PCI？

对于所有类型的Endpoin设备的Function，回答此问题相对简单。对于Memory请求和1/0请求，这个问题的确定基于Function 已编程响应的地址范围。对于Configuration请求，Type 0请求的目标设备从定义上来说就是“目标”，尽管如果设备处理未实现的Function时设备依然不会声明配置请求。

对于具有Type 1 header(Root Port、Switch和Bridge）的设备的Function，通常可以应用相同的问题，但是由于传统PCI桥的行为比Type 0 Function的行为更为复杂，因此在某种程度上很难确定答案。必须考虑Root Port和 Switch Port，就像它们实际上是由传统的PCI到PCI桥组成的一样，然后在每个阶段都要考虑虚拟桥的配置设置，以确定正确的行为。

PCI Express 消息在传统PCI中不存在，因此上述规则无法应用。当设备必须将请求作为Unsupported Request处理时，本规范专门针对每种消息类型进行了描述。消息通过Root Port和Switch Port 不受传统PCI控制机制（包括 Bus Master Enable 和电源状态设置）的影响。

请注意，PCI Express的Completer Abort（等同于Target Abort）仅用于指示严重错误，该错误使Completer永久无法响应原本应正常响应的请求。由于仅当目标已声明DEVSEL＃时才在传统PCI中使用Target Abort，因此对于传统PCI目标通过不声明 DEVSEL ＃会忽略请求的任何情况，使用Completer Abort是不正确的。

• 如果Request是一条消息，但消息编码指定了一个未定义的值，或者是一个与设备的Function不支持的消息对应的值（除了Vendor_Defined Type 1之外，该类型不被视为错误-see Table F-1)，则该Request是 Unsupported Request，这会根据Section 6.2的描述来报告。
  • 如果消息编码是受支持的值，则需按照相应的消息处理规则进行处理；如果消息编码是被忽略的消息，则接收侧忽略该消息且不用报告任何错误（请参阅Section 2.2.8.7）。
• 如果该请求是一条消息，其路由字段指示按ID路由，并且如果该请求是由具有Type O Header的 device Function接收的，则强烈建议将该设备视为该消息的目标，而不考虑在该请求的Destination ID字段中指定的总线号和设备号。
  • 如果Destination ID指定的Function是未实现的，强烈建议将该请求作为Unsupported Request处理，并按照Section 6.2的规定进行报告。
• 如果该请求违反了设备的Function的编程模型，则Function可以选择将请求视为一个Completer
  Abort，而不是正常处理请求。
  • 如果该请求被视为一个Completer Abort，则会为该Function报一个错误（see Section 6.2）。
  • 如果该请求需要一个Completion，则返回一个Completion Status为CA的Completion (seeSection
    2.2.8.10）。

IMPLEMENTATION NOTE

Optimizations Based on Restricted Programming Model

当设备的编程模型限制了（相对于PCI Express允许的限制）Request的特征时，允许该设备“Completer Abort”任何违反编程模型的请求。这包括对寄存器块的unaligned访问或wrong-size 访问以及对存储空间的unsupported size的访问。

通常，当所有通信都在设备驱动程序和设备本身之间进行时，设备可以采用受限的编程模型（Restricted Programming Model）。可以由操作系统软件或可能不理解该设备的受限编程模型的应用程序直接访问的设备（通常是实现传统功能的设备）应设计为支持所有类型的请求，这些请求可能存在于现有的使用模型中。如果不这样做，设备可能无法使用现有软件运行。

如果请求在发出FLR的到目标Function完成FLR之间到达，则允许该请求被丢弃（在更新流控制信用之后），而无需将其记录为错误或用信令通知一个错误。建议将该请求作为Unsupported Request(UR）处理。

• 否则（是个受支持的请求类型，且不是一个消息），则按以下方式处理：

  • 如果因为设备特定的错误条件，完成者无法处理该请求，则完成者必须尽可能将请求作为Completer Abort来处理。
    • 如果可以将错误分离给组件中的特定Function，则将报告与Function接收侧相关的错误；如果无法分离错误，则报告与该接收端口相关的错误（请参见Section 6.2）。
  • 仅对于配置请求，复位后设备可能会终止请求，但它必须表明设备只是暂时无法处理该请求，在将来需要能够处理该请求-在这种情况下，会返回一个Completion Status 为 Configuration Request Retry Status(CRS）的Completion（请参阅Section 6.6）。允许设备返回CRS的有效复位条件为：
    • Cold、Warm和Hot Reset。
    • FLR。
    • 为响应从D3hot到DOuninitialized设备状态转换而执行的复位。

  严禁设备的Function在设备的软件发起的复位（FLR除外）之后返回CRS，例如，通过设备的软件驱动程序写入设备特定的复位字段来实现。另外，在没有中间有效复位（即，FLR或常规复位）条件的情况下，设备的Function在先前返回一个Successful Completion之后不允许返回CRS。

  • 在设备的软件发出复位（FLR除外）之后，例如通过设备的软件驱动程序写入设备特定的复位字段，则device
    Function不允许返回CRS。在没有有效复位（即FLR或常规复位）条件的情况下，或者如果设置了Function的Status寄存器中的ImmediateReadiness字段，则device
    Function 在指示其Configuration-Ready（见Section 6.23）后不允许返回CRS。此外，device
    Function 不允许在没有有效复位（即，FLR或常规复位）条件的情况下先前返回Successful
    Completion之后返回CRS。

  • 在为请求提供服务的过程中，完成者可以确定请求是否必须作为错误处理，在这种情况下，将根据错误的类型来处理请求。

    • 一个示例：一个PCI Express/PCI Bridge
      刚开始可能接受请求，因为它指定了一个映射到桥的二级总线的内存空间范围，但是该请求可能会在桥的PCI侧执行Master
      Abort或Target Abort。从PCI Express角度来看，在这种情况下，请求的状态为UR(for Master
      Abort）或CA(for Target Abort）。如果请求要求在PCI Express上完成，则返回相应的Completion
      Status。

• 如果该请求需要返回一个Completion，则根据Completion的构成规则生成该Completion（请参阅Section2.2.9）。

  • Completion Status 根据处理收到的Request的结果来确定。
  • 如果请求有ECRC Check Failed错误，则是否返回完成取决于特定于实现，如果是，则返回用于完成状态的架构值。但是，强烈建议完成者返回带有UR完成状态的完成。

• 在正常工作条件下，PCI Express Endpoint 和Legacy Endpoint 接收 Posted Request的延迟绝不能超过10μs，这称为Posted Request Acceptance Limit。设备必须（a）设计为在必要的时限内处理收到的Posted Request并返回相关的流控制信用，或（b）依靠受限的编程模型来确保Posted Request
  不会通过以下方式发送到设备：软件或设备无法在必要的时间内接受新的Posted Request。

  • 在应用Posted Request Acceptance Limit的情况下，以下情况不被认为是正常的操作条件：
    • Fundamental Reset 后的一段时间（see Section 6.6）。
    • TLP重传或链路重新训练。
    • 一个或多个被丢弃的FCP(Flow Control Update）。
    • 设备处于诊断模式。
    • 设备处于一个设备特定的无法正常工作的模式。
  • 以下情况被认为是正常的操作条件，但它们引起的任何延迟均不会计入Posted Request Acceptance Limit：
    • 上行的TLP业务延迟了上行的FCP。
    • 链路从一个低功耗状态退出。
    • VC在做业务冲裁。
    • 尽管不是必需条件，但强烈建议RC Integrated Endpoint 也遵守 Posted Request Acceptance Limit。

• 如果设备支持作为I/0写入的目标（即 Non-Posted Request)，则强烈建议采用与Posted Request
  相同的时限返回每个对应的Completion，尽管这不是必需的。

IMPLEMENTATION NOTE

Restricted Programming Model for Meeting the Posted Request Acceptance Limit

某些硬件设计可能无法在要求的接收时限内处理每个Posted Request。一个示例是写入命令队列，其中有的命令的完成所花费的时间可能超过接收时限。当该设备当前正在处理先前的写入时，对该设备的后续写入可能会超过接收时限。这样的设备可能依赖于受限的编程模型，其中设备驱动程序会限制写设备的速度，驱动程序会在发出写事务之前轮询设备以确定缓冲区可用性，或者驱动程序会实现一些其他基于软件的流控机制。

Figure 2-43 Flowchart for Handling of Received Request

IMPLEMENTATION NOTE
Configuration Request Retry Status

某些设备需要很长的自初始化过程才能完成，然后才能处理配置请求（与PCI上的智能1/0解决方案相同）。PCI/PCI-X体系结构已指定复位后的 225 (PCI）或 226 (PCI-X）时钟恢复时间Trhfa以提供此类设备所需的自初始化时间。Section 6.6.1为PCle设备定义了一个1.0s的恢复周期。PCle架构也提供了一种可以作为替换的策略，即通过实现Configuration Request Retry Status (CRS）Completion Status，来等待这种最坏情况下的恢复时间。在有效复位之后接收到配置请求的设备可以以CRS Completion Status 响应以终结该请求，从而有效地停止配置请求，直到子系统完成本地初始化并准备与主机通信为止。请注意，以CRS Completion Status 响应配置请求是合法的。发送此Completion Status 响应任何其他请求类型是非法的（请参阅Section 2.3.2）。在某些情况下，Readiness Notifications (see Section 6.23）和 Immediate Readiness (see Section 7.5.1.1.4 和 Section 7.5.2.1）也禁止使用CRS Completion Status。

请求者收到具有CRS Completion Status的Completion会终止发送配置请求。RC针对最开始的配置请求的进一步措施在Section 2.3.2中指定。

实现CRS软件可见性的RC可以向软件报告收到的CRS Completion Status，从而使软件可以执行其他任务，而不会在设备完成其自我初始化时停滞。打算利用此机制的软件必须确保在有效的复位之后对设备的首次访问是配置读请求，该请求将访问设备配置空间头中的Vendor ID字段的两个字节。仅在这种情况下，RC将为Vendor ID字段合成一个特殊的读取数据值，以向软件指示设备已返回CRS Completion Status。对于其他配置请求，或在未启用CRS软件可见性的情况下，RC通常会重新发出配置请求，直到它以Section 2.3.2中所述的除CRS以外的Completion Status为止。

当系统中包含PCI Express to PCI/PCI-X Bridge时，系统软件和／或RC必须遵守Section 2.8和Section 6.6所述的为PCI/PCI-X agent 定义的Trhfa的限制，以避免一些不当行为。同样，使用PCI Express组件且需要额外的自我初始化时间（超过最小保证时间）的系统，必须提供某种机制来重新发出以CRS状态终止的配置请求。在运行基于传统PCI/PCI-X的软件的系统中，RC必须使用硬件机制重新发出配置请求，以确保正确枚举系统。

参阅Section 6.6获取更多关于复位的信息。

2.3.1.1 Data Return for Read Requests

• Memory Read Request的各个 Completion可能会提供少于该请求的数据量，只要该请求的所有Completion携带的数据量在合并后等于该请求的数据量即可。

  • 不同其请求的Completion不能合并。

  • 1/0读和配置读只用返回一个Completion。

  • Completion的Completion Status 仅对应于与该Completion返回的数据相关的状态。

    • 状态为Successful Completion 以外的Completion会终止单个Read Request的所有Completion。

      • 这种情况下，Length字段的值是未定义的，且必须被接收器忽略。

• Completion 携带的数据量不能大于Max_Payload_Size指定的值。

  • 接收器必须检查此规则，参阅Section 2.2。

Note：这只适用于所有携带有效负载的TLP。

• Memory Read Request 可以有一或多个Completion。

• 在用多个Completion为Memory Read Request 提供服务时 Read Completion Boundary(RCB）确定了自然对齐的地址边界。

  • 对于一个RC,RCB为64byte或128 byte。
    • 该值在Link Control寄存器中报告（see Section 7.5.3.7）。

  Note:Bridge和Endpoint 可以实现一个相应的命令字段，该字段可以由系统软件设置，以指示RC的RCB值，从而允许Bridge或Endpoint在RC的RCB为128byte时优化其行为。

  • 对其他设备类型，RCB为128byte。

• 不以RCB字节整数倍跨越自然对齐地址边界的Request的Completion，必须包括请求中指定的所有数据。

• 可以使用多个Completion来处理以RCB字节整数倍的方式跨越地址边界的请求，但是除沿以下地址边界外，不得对数据进行分段：

  • 第一个Completion 必须以请求中指定的地址开始，并且必须以以下其中一个结束：
    • 请求中指定的地址加上请求中指定的长度（即整个请求）。
    • 请求的开始和结束之间的地址边界，为RCB字节的整数倍。
  • 最后一个Completion必须以请求中指定的地址加上请求中指定的长度结尾。
  • 第一个和最后一个Completion之间的所有Completion 必须是RCB字节长度的整数倍。

• 接收侧可以选择检查是否违反了RCB∘。如果执行此检查的接收者确定Completion违反了此规则，则它必须将该Completion 作为一个Malformed TLP处理。

• 一个Memory Read Request的多个Completion 必须以地址递增的方式返回数据。

• 对于每个Memory Read Request的Completion，除非BCM位为1b，否则Byte Count字段必须指示完成该请求所需的剩余字节数，包括随该Completion返回的字节数。（注：只有PCI-X的完成者的BCM会设置为1b。）

  • 按Table 2-38所示计算完成Memory Read Request 所需的字节总数。
  • 5如果使用多个Completion完成了 Memory Read Request，则每个连续Completion的字节计数值是前一个Completion指示的值减去前一个Completion返回的字节数。

• Completion Data的范围从请求指定的DW地址开始。在第一个或唯一完成的第一个或唯一Data DW中，只有在Request的First BE字段中配置为有效的字节才包含有效数据。在请求的First BE字段中配置为无效的字节将返回未定义的内容。

• 在最后一次成功完成的最后一个 Data DW中，仅在Request的Last BE字段中配置为有效的字节包含有效数据。在Request的Last BE字段中配置为无效的字节将返回未定义的内容。

• CRC运算包括所有完成数据字节，也包括其中内容不确定的字节。

• Figure 2-44给出了以上示例。该示例假定返回单个Completion TLP。

Figure 2-44 Example Completion Data when some Byte Enables are Ob

IMPLEMENTATION NOTE

BCM Bit Usage

为了满足某些PCI-X协议约束，在某些情况下，用于PCI-X突发读取的PCI-X Bridge或PCI-X Completer将在拆分的Completion 序列的第一个PCI-X事务中设置Byte Count字段，以指示第一个事务的大小，而不是整个突发读取的大小。在这种情况下， PCI-X Bridge/PCI-X Completer将在第一个PCI-X事务中将BCM位置1，以指示Byte Count字段已从其正常使用中被修改。有关更多详细信息，请参阅《PCI-X Addendum to the PCI Local Bus Specification, Revision 2.0》。

一个PCI Express的Memory Read Requester 必须能够正确处理PCI-X Bridge/PCI-X Completer将BCM设置为1的这种情况。当这种情况发生时，第一个读请求的Completion会把BCM设置为1，指示Byte Count字段报告的只是该第一个数据包的大小，而不是

整个剩余字节数。在这一点上，请求者不应该得出读完成的其他分组丢失的结论。

BCM字段永远不会在读完成的后续数据包中设置为1，因此这些后续数据包中的Byte Count字段将始终指示每个Completion的剩余字节数。因此，请求者可以使用这些数据包中的Byte Count字段来确定是否缺少读完成的其他数据包。

PCI Express Completer 永远不会将Byte Count字段设置为1。

Table 2-38 Calculating Byte Count from Length and Byte

注26:Last DW BE为0000b只允许Length字段为1DW的情形。

注27：长度是DW的数量，如Length字段中的值所指示，并乘以4以得出一个以字节为单位的数字。

• 对所有的Memory Read Completion,Lower Address字段必须指示该Completion返回的数据的第一个启用字节的字节地址的低位。
  • 对于第一个（或唯一一个）Completion，完成者可以从Request的地址的最低有效5位与2位字节级地址（如Table2-33所示）连接起来，生成此字段。
  • 对于任何后续Completion,Lower Address字段将始终为零，但由RCB值为64byte的RC生成的Completion除外。在这种情况下，Lower Address字段的最低有效6位将始终为零，而Lower Address字段的最高有效位将根据64byte数据有效载荷的对齐方式进行计算。

Table 2-39 Calculating Lower Address

·当一个Read Completion 携带一个非 Successful Completion的 Completion Status：

如果该Completion中不携带数据：

用Cpl或CplLk替代CpID或CpIDLk。

如果该Completion是Request的最后一个Completion：

Completer 必须不再为该Request返回另外的Completion。

示例：完成者将请求分为四个部分进行服务；第二个Completion 携带 Completer Abort的 Completion Status；完成者终止了对请求的服务，并且没有传输其余的两个完成。

• Byte Count 字段必须指示完成该请求所需的剩余字节数（就像Completion Status是Successful Completion一样）。

• 如果 Completion Status 为 Successful Completion，则Lower Address 字段必须指示将随Completion 返回的数据的第一个启用字节的字节地址的低位比特。

IMPLEMENTATION NOTE

Restricted Programming Model

当设备的编程模型限制了（相对于PCI Express所允许的限制）向该设备发出的Read Request的大小和／或对齐方式时，允许该设备对违反编程模型的Read Request使用Completer Abort的Completion Status。这暗示着这样的设备，通常是所有通信将在设备的驱动程序和设备本身之间进行通信的设备，不一定需要执行生成长度RCB的完成所需的缓冲。但是，在所有情况下，对于设备将以Successful Completion状态完成的所有读取，都必须遵守RCB指定的边界。

Examples:

1. 地址为10000h且长度为Coh字节（十进制192）的Memory Read Request 可以由具有64 byte的RCB值的RC来完成，并具有以下Completion的组合之一：

192-or-128,64-or-64,128-or-64,64,64

2. 地址为10000h且长度为Coh字节（十进制192）的Memory Read Request 可以由具有128 byte的RCB值的RC来完成，并具有以下Completion的组合之一：

192-or-128,64

3. 地址为10020h且长度为100h字节的Memory Read Request 可以由具有64 byte的RCB值的RC来完成，并具有以下Completion的组合之一：

256-or-32,224-or-32,64,160-or-32,64,64,96-or-32,64,64,64,32-or-32,64,128,32-or- 32, 128,96-or-32,128,64,32-or-96,160-or-96,128,32-or-96,64,96-or-96,64,64,32-or-160, 96 -or-160,64,32-or-224,32

4.地址为10020h且长度为100h字节的Memory Read Request 可以Endpoint来完成，并具有以下Completion的组合之一：256-or-96,160-or-96,128,32-or-224,32

2.3.2 Completion Handling Rules

• 设备发出了outstanding Request，当该设备收到了与这些请求的Transaction ID不匹配的Completion时，该Completion称为"Unexpected Completion"。

• 如果收到的Completion与outstanding Request的Transaction ID相匹配，但其他字段与相应请求不匹配（例如，Attributes、Traffic Class、Byte Count、Lower Address等），则强烈建议接收方以Malformed TLP处理该Completion。

  • 完成者不得在Completion 中检查 IDO Attribute(Attribute Bit 2)，因为请求者不需要按照Section
    2.2.6.4和Section 2.2.9的规定将IDO值从请求复制到该请求的Completion中。
  • 但是，如果以其他方式正确构造了Completion，则允许接收方将完成作为Unexpected Completion进行处理。

• 当Switch的Ingress Port收到无法转发的Completion时，该Ingress Port 必须将该 Completion
  作为 Unexpected Completion 处理。这包括针对以下目标的Completion：

  • 与Upstream Port 关联的设备中不存在的Function，

  • 与Upstream Port 关联的总线上不存在的设备，

  • 内部交换结构上不存在的设备或功能，或Downstream Port的Bus Number 在Upstream Port的Bus Number 范围内，但该Downstream Port未声明。

• 收到Unexpected Completion是一个错误，必须根据以下规则进行处理：

  • 收到Unexpected Completion的设备必须丢弃该Completion。

  • Unexpected Completion 会由相关接收端口来报告该错误（see Section 6.2）。

Note：假定发生Unexpected Completion的原因主要是由于Switch对Completion的错误路由。在这种情况下，发出请求的请求者可能不会收到其请求的完成，并且请求者的完成超时机制（请参见Section 2.8）将终止请求。

• 具有除 Successful Completion 或 Configuration Request Retry Status（这个只会用来响应配置请求）之外的其他Completion Status的Completion 会导致Requester必须执行下述操作：
  • 释放完成缓冲区空间并请求关联的其他资源。
  • 通过请求者专用机制处理该错误（请参见Section 6.2.3.2.5）。

如果Completion是在启动FLR到目标Function完成FLR的时间之间到达的，则允许将该完成作为Unexpected Completion 进行处理，或者将其静默丢弃（在更新流控制信用之后），而无需进行日志记录或将其表示为错误。一旦完成FLR，除非已重新启用该Function以发出请求，否则必须将与在FLR之前发出的请求相对应的收到完成作为Unexpected Completion处理。

• RC怎么处理携带Configuration Request Retry Status的Completion是特定于实现的，但系统复位后的时间除外（请参阅Section 6.6）。对于支持CRS软件可见性的RC，以下规则要遵守：
  • 如果未启用CRS软件可见性，则RC必须重新发出配置请求作为新请求。
  • 如果启用了CRS软件可见性功能，则：
    • 针对设备的Function的配置空间头的Vendor ID字段的两个字节的配置读请求，RC必须通过为Vendor ID字段返回0001h的读取数据值，并且为其余字节返回全1来完成该请求并送往主机。此读取数据值已被PCI-SIG专门为此保留，并不与任何分配的Vendor ID对应。
    • 对于Configuration Write Request 或任何其他 Configuration Read Request,RC必须重新发出配置请求作为新请求。

RC实现可以选择在确定请求的目标有问题之前采取限制 Configuration Request/CRS的Completion Status 循环的数量，并采取适当的措施，例如将请求作为失败的事务完成发送给主机。

可以通过Root Control寄存器中的CRS Software Visibility Enable 字段启用CRS软件可见性（请参见 Section 7.5.3.12)，以基于单个Root Port来控制RC行为。或者，可以通过Section 7.9.7.4所述的RCRB控制寄存器中的CRS Software Visibility Enable 字段来管理RC行为，从而允许一个或多个Root Port或RC Integrated Endpoint的行为由单个字段来控制。对于这种替代情况，每个Root Port或RC Integrated Endpoint 通过 RC Link Declaration Capability 中的RCRB头关联，声明其与特定的使能位的关联（请参见Section 7.9.8）。每个Root Port或RC Integrated Endpoint 最多允许一个使能位进行控制。因此，例如，禁止其Root Control 寄存器包含使能字段的根端口声明与RCRB的RCRB头关联，而RCRB的RCRB头功能中也包含使能位。根端口或RCRB头功能中是否存在使能位由相应的CRS Software Visibility Enable 字段指示（分别参见 Section 7.5.3.13和 Section7.9.7.3)。

• 配置请求以外的请求返回 Configuration Request Retry Status的Completion是非法的。接收者可以选择将这些违规行为报告为Malformed TLP。
• Completion Status 为保留值的Completion 被视为 Unsupported Request (UR）。
• Completion Status 为 Unsupported Request 或Completer Abort的Completion使用传统PCI报告机制来报告（see Section 7.5.1.1.4)。
  • 请注意，由此错误条件触发生成的Completion由Completer 报告，如Section 6.2所述。
• 如果收到了一个Completion Status 为非 Successful Completion的 Read Completion 或 AtomicOp Completion，则：
  • 如果该Completion没有携带数据：
    • 用Cpl（或CplLk）替代CpID（或CpIDLk）。
  • 如果该Completion是该请求的最后一个Completion：
    • 请求者必须认为该请求已终止，并且不能期望接收到其他Completion。

示例：请求者收到已发出的128字节读请求的32字节读数据，然后接收到Completion Status为 Completer Abort的Completion。然后，请求者必须释放为该特定读取请求分配的内部资源。

IMPLEMENTATION NOTE

Read Data Values with UJR Completion Status

当配置读请求终止为Unsupported Request时，某些系统配置软件依赖于读取全1的数据值，尤其是在探查系统中是否存在设备时。当针对配置读请求返回UR完成状态时，旨在与软件配合使用的RC必须合并此值，该读取数据的值必须为全1。

2.4 Transaction Ordering

2.4.1 Transaction Ordering Rules

Table 2-40定义了PCI Express Transactions的排序要求。下表中定义的规则统一适用于PCI Express上的所有事务类型，包括Memory、I/O、Configuration和Message。该表中定义的排序规则适用于单个业务类别（TC）。具有不同TC值的Transaction之间没有排序要求。请注意，这也意味着在流经不同虚通道的业务之间不需要排序，因为不允许将具有相同TC值的事务映射到任何PCI Express链路上的多个VC。

对于Table 2-40，列代表首次发出的Transaction，行代表随后发出的Transaction。该表条目指示两个Transaction之间的排序关系。表条目定义如下：

注：规范中的“pass”指的是超过的意思，即把顺序提前。那么对于Table 2-34的理解需要问这么一个问题：即行代表的TLP能否调度到列代表的TLP之前传输？

• Yes-必须允许第二个事务（行）在第一个事务（列）之前传输，以避免死锁。（发生阻塞时，第二笔事务需要在第一笔事务之前传输。必须理解公平性，以防止饥饿。）

• Y/N-没有任何要求。第二笔事务在第一笔事务之前或之后传输都可以，或者被其阻塞。

• No-不允许第二笔事务在第一笔事务之前传输。这是支持生产者-消费者强顺序模型所必需的。

Table 2-40中行头和列头信息介绍如下：

Posted Request 指 Memory Write Request 或 Message Request。

Read Request 指 Configuration Read Request、I/O Read Request 或 Memory Read Request。

NPR (Non-Posted Request) with Data 指 Configuration W/rite Request、I/O Write Request 或AtomicOp Request。

Non-Posted Request 指 Read Request 或 NPR with Data。

Table 2-34中每个条目的解释如下：

A2a 除非A2b适用，否则Posted Request不得调度到另一个Posted Request之前传输。

A2b

设置了RO字段的Posted Request允许调度到另一个Posted Request之前传输。如果两个Requester ID不同，则允许设置了IDO字段的Posted Request 调度到另一个Posted Request之前传输。

其中RO指的是RelaxedOrdering Attribute字段。

某些用法通过不实现这种传递来启用（请参见Section 7.8.15节中的No RO-enabled PR-PR Passing字段）。

A3,A4 Posted Request 允许调度到Non-Posted Request之前传输。

A5a Posted Request是允许调度到Completion之前的，但是除非应用了A5b，否则不这么做。

A5b 在一个PCI Express to PCI/PCI-X Bridge 中工作在传统PCI模式的PCI/PCI-X总线，对于从PCI Express到PCI方向的传输事务，Posted Request 必须要能够调度到Completion之前以防止死锁。

B2a 除非应用了B2b，否则Read Request不能调度到Posted Request之前传输。

B2b 如果Read Request和Posted Request的Requester ID不一样，则设置了IDO字段的Read Request可以调度到Posted Request之前传输。

附加规则：

• PCI Express Switch 允许将Relaxed Ordering字段设置为1的Memory Write或Message Request 调度到任何之前的朝同一方向传输的Memory Write或Message Request之前。Switch转发时不能修改Relaxed Ordering字段的值。RC也被允许以任何顺序将请求中的数据字节写入系统内存（必须将字节写入正确的系统内存地址。他们的写入顺序是未定义的）。

• 对RC和Switch,Memory Write合并是禁止的（如PCI Local Bus Specification 描述）。
  - Note：这是必需的，设备可以针对与其期望的大小相匹配的Memory Write size优化其接收缓冲区和控制逻辑，而无需支持最大可能的Memory Write的 payload size。

• 合并Memory Read Request，或合并不同Request的Completion是被禁止的。

• No Snoop字段不影响顺序。

• 对于RootPort和SwitchDownstreamPort,Posted Request或Completion的接收不依赖同一业务类别中 Non-Posted Request 的传输（27）。

• 对于Endpoint、Bridge和Switch Upstream Port,Posted Request的接收必须不依赖于来自同一业务类别中的同-Upstream Port 的任何TLP的传输（27）。

• 对于Endpoint、Bridge和Switch Upstream Port, Non-posted Request的接收必须不依赖于来自同一业务类别中的同-Upstream Port的Non-posted Request的传输（27）。

• 对于Endpoint、Bridge和 Switch Upstream Port,Completion的接收必须不依赖于来自同一业务类别中的同-Upstream Port 的任何TLP的传输（27）。

  • 请注意，决不允许Endpoint阻塞 Completion。

• 针对Non-Posted Request 发出的 Completion 必须与该 Non-Posted Request 有相同的业务类别。

• Switch和支持对等操作的RC必须对所有转发的业务强制执行这些事务排序规则。

注27：满足上述规则是确保无死锁操作的必要但非充分条件。无死锁操作取决于系统拓扑，支持的虚通道数以及配置的业务类别到虚通道的映射。平台和系统约束的规范，以及确保无死锁操作不在本规范的范围内（有关该问题的讨论，请参阅Appendix D）。

为确保无死锁操作，设备不应将业务从一个虚通道转发到另一虚通道。用于避免设备在虚通道之间转发或转换事务的系统中出现死锁的约束规范不在本文档的讨论范围内（有关问题的讨论，请参阅Appendix D）。

IMPLEMENTATION NOTE

Large Memory Reads vs. Multiple Smaller Memory Reads

请注意，与Table 2-34中的条目D5b相关联的规则确保对于一个Memory Read Request的多个Completion将按地址顺序返回完成内容。但是，与条目D5a关联的规则允许不同 Memory Read Request的不同Completion 可以以与请求的发送顺序不同的顺序返回。例如，如果设备从位置1000h发出一个256字节的单个Memory Read Request，并且使用两个128字节的Completion 返回，则可以确保两个Completion按以下顺序返回：

第一个Completion携带从地址1000h到107Fh的数据；

第二个Completion携带从地址1080h到10FFh的数据。

但是，如果设备发出两个128字节的Memory Read Request，第一个针对地址1000h，第二个针对地址1080h，则两个完成操作可能以以下任一顺序返回：

第一个Completion携带从地址1000h到107Fh的数据；

第二个Completion携带从地址1080h到10FFh的数据。

or

第一个Completion携带从地址1080h到10FFh的数据；

第二个Completion携带从地址1000h到107Fh的数据。

2.4.2 Update Ordering and Granularity Observed by a Read Transaction

本节讨论一个Memory读请求返回的数据写入缓冲区的顺序，以及数据的粒度。

如果使用单个事务的请求者从完成者读取一个数据块，并且正在同时更新完成者的数据缓冲区，则多个更新的顺序和每个读取的返回数据中所反映的更新粒度不在此规范范围之内。这既适用于PCI Express写入事务执行的更新，也适用于其他机制（例如，主机CPU更新主机内存）执行的更新。

如果使用单个事务的请求者从完成者读取一个数据块，并且该完成者的数据缓冲区同时由一个或多个不在PCI Express结构上的实体更新，则更新的顺序和每个读取返回的数据反映的更新粒度不在本规范范围之内。

作为更新顺序的示例，假设数据块位于主机内存中，并且主机CPU首先写入位置A，然后写入不同的位置B。一个请求者使用单个读取事务读取该数据块不能保证请求者能监测到这个更新顺序。换句话说，无论数据块中位置A和B的位置如何，请求者都可以观察到位置B的更新值和位置A的旧值。除非完成者对更新顺序做出自己的保证（在本规范之外），否则依赖更新顺序的请求者必须通过一次读取事务来观察对位置B的更新，然后再发起对位置A的后续读取以返回其更新的值。

作为更新粒度的示例，如果主机CPU将QWORD写入主机内存，则从主机内存中读取该QWORD的请求者可能会观察到一部分QWORD更新，而另一部分包含旧值。

尽管本规范没有要求，但强烈建议主机平台确保当主机CPU将对齐的DWORD或对齐的QWORD写入主机内存时，PCI Express 读取的更新粒度将不小于DWORD。

IMPLEMENTATION NOTE

No Ordering Required Between Cachelines

允许从主机内存请求多个缓存行的单个内存读取的完成者的RC，可以同时获取多个缓存行，以帮助促进多缓存行的完成，但要取决于Max_Payload_Size。这些高速缓存行提取之间不需要排序关系。

2.4.3 Update Ordering and Granularity Provided by a Write Transaction

本节讨论一个Memory写请求的数据写入内存的顺序以及粒度。

如果完成者接收了包含多个DWORD且Relaxed Ordering字段为0的单个写事务，则观察到的完成者数据缓冲区中位置更新的顺序必须以地址顺序递增。如果沿路径的PCI或PCI-X桥将多个写事务组合到单个事务中，则需要使用此语义。但是，观察到的对Completer数据缓冲区更新的粒度超出了本规范的范围。

尽管本规范没有要求，但是强烈建议主机平台确保在PCI Express写入更新主机内存时，主机CPU观察到的更新粒度将不小于DWORD。

作为更新顺序和粒度的示例，如果请求者将QWORD写入主机内存，则在某些情况下，从主机内存读取QWORD的主机CPU可以观察到更新的第一个DWORD以及包含旧值的第二个DWORD。

2.5 Virtual Channel (VC) Mechanism

虚通道（VC,Virtual Channel）机制为在整个结构中使用TC字段区分的业务提供了支持。VC机制需要独立的硬件资源（队列／缓冲区和关联的控制逻辑）支持。这些资源用于在不同VC之间具有完全独立的流控制的情况下通过链路传输信息。在单个业务流可能会对系统内所有业务造成瓶颈的情况下，这是解决流控制引起的阻塞问题的关键。

通过将有特定TC值的数据包映射到其对应的vC，从而将业务与VC相关联。VC和MFVC机制允许将TC灵活映射到VC。最简单的形式是TC可以按1:1映射到VC。为了权衡性能／成本，PCI Express提供了将多个TC映射到单个VC的能力。Section 2.5.2介绍了TC到VC映射的详细信息。

当一个或多个TC与由VCID指定的物理VC资源相关联时，便建立了虚通道。该过程由配置软件控制，如Section 6.3、Section 7.9.1和Section7.9.2所述。

默认TCO/VCO对的映射是必须实现的、是“硬连线”的，并且所有组件都必须支持，其他的TC和VC的映射是可选实现的。因此，最基本的TC/VC设置不需要任何特定于Vc的硬件或软件配置。为了确保互操作性，未实现可选的Virtual Channel Capability structure 或 Multi-Function Virtual Channel Capability structure的组件必须遵守以下规则：

• Requester 只能生成带有TCO标签的请求。（请注意，如果请求者以TCO以外的TC标签发起请求，则该请求可能被链路另一端实现VC capability并执行TC过滤的组件视为格式错误的TLP。）
• 完成者必须能接收TC标签不是TCO的请求，并且必须保留TC标签，即，它生成的任何完成都必须有与请求相同的TC标签。
• Switch必须将所有TC映射到VCo，并且必须转发所有事务，而不管TC标签是什么。

如果设备的某个Function能够生成TC标签不是TCO的请求，则即使它只支持默认VC，该Function也必须实现合适的vc或MFVC Capability structure。比如说Endpoint或Root Port的Function类型。为了启用默认以外的TC映射，这是必需的。而且这种操作必须遵循TC/VC映射规则用VC和MFVC Capability structure的软件编程实现。

Figure 2-45说明了虚通道的概念。从概念上讲，流经VC的业务在发送端多路复用到公共物理链路资源上，并在接收端多路分解成单独的VC路径。

Figure 2-45 Virtual Channel Concept-An Illustration

在Switch内部，每个虚通道都需要专用的物理资源（队列／缓冲区和控制逻辑），以支持Switch内部独立的业务流。Figure 2-46从概念上显示了Switch中支持上游方向业务流的VC资源。

Figure 2-46 Virtual Channel Concept-Switch Internals (Upstream Flow)

multi-Function 设备可以实现类似于Switch中那些资源的子集的虚通道资源，目的是管理从不同Function到设备 Upstream Egress Port的上行请求的 QoS。

IMPLEMENTATION NOTE

VC and VC Buffering Considerations

每个架构VC最小的缓冲区大小是特定于实现的。

给定架构的链路上的所有VC的缓冲区最小值不需要相同，即，具体实现可以根据使用模型和其他链路属性（例如，链路宽度和信令）为选定的VC提供合适的缓冲深度。

实现可以从配置和VC是否启用推导出特定于实现的策略来调整每个VC的缓冲，例如，如果实现了四个VC但仅启用了两个，则实现可以将未启用的VC缓冲分配给启用的VC，这样可以降低链路流控引起的反压的可能性，提高系统的效率／性能。

多端口组件（Switch或RC）的每个Port的VC数量和每个VC的缓冲区大小可以不一样。

2.5.1 Virtual Channel Identification (VC ID)

PCI Express的端口可以支持1-8个虚通道-每个端口都是独立配置／管理的，因此允许实现根据需求更改每个端口支持的VC 数量。这些VC使用虚通道标识（VCID）机制进行唯一标识。

请注意，尽管DLLP包含用于流控制计数的VCID信息，但TLP却不包含。如Section 2.5.2所述，使用TC到VC的映射在链路的每个端口上完成TLP与VCID的关联，以进行流控制计数。

根据Section 7.9.1中的定义，所有支持不止VCO的端口必须至少提供一个VC Capability structure。允许 multi-Function 设备实现Section 7.9.2中定义的 MFVC Capability structure。对于仅支持默认TCO/VCO配置的端口，提供这些扩展结构是可选的。配置软件负责为这些VC配置链路两侧的端口。这是通过扫描层次结构并使用端口的VC或MFVC Capability寄存器（支持更多的默认vco）来为链路建立对应VC数量来实现的。为端口内的VC硬件资源分配VCID的规则如下：

• 每个端口的VCID分配必须唯–即无法将同一VCID分配给同一端口内的不同vc硬件资源。
• 链路两侧的两个端口的VCID分配必须相同（VC数量以及ID都要匹配）。
• 如果 multi-Function 设备实现 MFVC Capability structure，则其VC硬件资源与其Function的任何VC Capability structure的VC硬件资源是不同的。VCID唯一性要求（上述第一条规则）仍单独适用于MVFC和任何VC功能结构。另外，VC ID cross-Link的匹配要求（上述第二条规则）适用于MFVC Capability structure，但不适用于Function的VC Capability structure。
• VC ID 0固定分配给默认VC。

2.5.2 TC to VC Mapping

所有的业务都必须要映射到某个VC上。TCO到VCO的映射是默认的。

把TC映射到非VCO是需要系统软件指定的。但是，映射算法必须服从以下规则：

• 一个或多个TC可以映射到一个VC。
• 一个TC不能映射到任意Port或Endpoint Function的多个VC上。
• 链路两侧的Port上的TC/VC映射必须一致。

Table 2-41给出了一个TC/VC映射示例。

Table 2-41 TC to VC Mapping Example

注意下述规范描述习惯：

• TCn/VCk=TCn映射到VCk。

• TC(n-m)/VCk=所有在n到 m范围内的TC都映射到相同的VCk0

• TC[n:m]/VC[n:m]=TCn/VCn,TCn+1/VCn+1,…, TCm/VCm

Figure 2-47提供了几种不同链路配置中TC/VC映射的说明。有关TC/VC的其他注意事项，请参阅Section 6.3。

Figure 2-47 An Example of TC/VC Configurations

2.5.3 VC and TC Rules

以下是与TC/VC机制相关的关键规则的摘要：

• 所有设备必须支持通用I/O业务类别即TCO，并且必须实现默认的 VCO∘
• 每个VC拥有独立的流控机制。
• 不同TC之间不需要有排序关系。
• 不同vC之间不需要有排序关系。
• Switch的对等传输能力适用于Switch支持的所有虚通道。
• multi-Function 设备在不同Function之间的对等传输能力适用于multi-Function设备支持的所有虚通道。
• 接收设备收到的TLP的TC没有映射到Ingress Port中任何已启用的vc上，则此TLP视为Malformed TLP。
• 对于Switch,TLP的TC没有映射到目标Egress Port中任何已启用的VC上，则此TLP视为Malformed TLP。
• 对于Root Port,TLP的TC没有映射到目标RCRB中任何已启用的vc上，则此TLP视为Malformed TLP。
• 对于有一个MFVC Capabilitystructure的multi-Function设备，TLP的TC没有映射到MFVC
  Capabilitystructure中任何已启用的vc上，则此TLP视为Malformed TLP。
• Switch的每个Port必须支持独立配置TC/VC映射。
• RC的每个RCRB、关联的根端口和任何RC Integrated Endpoint 都比支持独立配置TC/VC映射。

有关VC和TC机制的更多详细信息，比如配置、映射和仲裁，请参阅Section 6.3。