PCIe Base Specification解析（三）

2.2.7 Memory, I/O, and Configuration Request Rules

下述规则适用于Memory请求、I0请求和配置请求。

• 除了公共的header字段外，所有Memory请求、I0请求和配置请求还包括以下字段：

  • Requester ID[15:0] 和Tag[9:0]，组成了Transaction ID。

  • Last DW BE[3:0］和1st DW BE[3:0］字段。对于TH字段置1的Memory Read Request 和 AtomicOp Request,header中的Last DW BE[3:0］和 1st DW BE[3:0］字段被重新用于携带ST[7:0］字段。对于TH字段设置为0的Memory Read Request，请参见Section 2.2.5的First/Last DW Byte Enable的规则。对于TH字段置1的AtomicOp Request,DW BE字段的值隐含为保留值。对于TH字段设置为0的AtomicOp Request,DW BE字段为保留值。

Memory Request 要遵循以下规则：

· Memory Request 采用地址路由，有32bit地址格式和64bit地址格式，见Figure 2-17和Figure 2-18。

Figure 2-17 Request Header Format for 64-bit Addressing of Memory

Figure 2-18 Request Header Format for 32-bit Addressing of Memory

• Memory Read Request的Length 字段的值不能超过Max_Read_Request_Size （见 Section
  7.5.3.4）。

• 对于AtomicOp Request, Table2-12中指定了架构化的操作数大小及其关联的Length字段值。完成者必须检查Length字段值。如果该值与设计值不匹配，则完成者必须将TLP作为Malformed TLP处理。否则，如果该值与完成者支持的操作数大小不匹配，则完成者必须将TLP作为不支持的请求（UR）处理。这将报告的与接收端口相关的错误（请参见Section6.2）。

  • FetchAdd Request 包含一个操作数，即要“add”的值。

  • Swap Request 包含一个操作数，即要"swap"的值。

  • CAS Request 包含两个操作数。数据区域中的第一个是"compare"”值，第二个是"swap"值。

Table 2-12 Length Field Values for AtomicOp Requests

• 对于AtomicOp Request，地址必须自然地与操作数大小对齐。完成者必须检查是否违反此规则。如果TLP违反此规则，则该TLP为Malformed TLP。这将报告的与接收端口相关的错误（请参见Section 6.2）。
• Request 指定的Address/Length组合不能导致一个跨4KB边界的内存空间访问。

  • 接收者可以选择检查是否违反此规则。如果执行此检查的接收方确定TLP违反了此规则，则该TLP是Malformed TLP。

  • 对于AtomicOp Request，会强制Completer检查用于地址自然对齐，所以它已经保证访问不会跨4KB边界，因此不需要单独的4KB边界检查。

  • 请注意，如果对 AtomicOp CAS Request执行了4KB边界检查，则此检查必须能够理解基于两个操作数的TLP
    Length值的大小，而对内存空间的访问则基于一个操作数的大小。

IMPLEMENTATION NOTE

Generation of 64-bit Addresses

强烈建议PCI Express Endpoint 能够生成完整范围的64位地址。但是，如果PCI Express Endpoint 支持较小的地址范围，并且无法达到给定平台环境所需的完整地址范围，则相应的设备驱动程序必须确保所有内存事务目标缓冲区都在Endpoint支持的地址范围内。确保这一点的方法是特定于平台和操作系统的，并且超出了本规范的范围。

I/O请求要遵循以下规则：

• I/O Request 采用地址路由，且只能使用32bit地址格式（see Figure 2-19）。

Figure 2-19 Request Header Format for I/O Transactions

• ·I/O Request 有以下限制：

  • TC[2:0］必须等于000b。

  • LN不适用于I/O Request，必须设置为保留值。

  • TH不适用于I/O Request，必须设置为保留值。

  • Attr[2］为保留值。

  • Attr[1:0］必须等于00b。

  • AT[1:0］必须等于00b。不建议接收者检查这两比特。

  • Length[9:0］必须等于0000000001b。

  • Last DW BE[3:0］必须等于0000b。

接收者可以选择检查是否违反了这些规则（但不能检查保留位）。这些检查是独立可选的（请参见Section 6.2.3.4）。如果实施这些检查的接收方确定TLP违反了这些规则，则该TLP是Malformed TLP。

	 - 如果实现，这将报告的与接收端口相关的错误（请参见Section 6.2）。

配置请求要遵循以下规则：

• Configuration Request 采用ID路由，并使用3DW header。
• 除了所有Memory、I/0和Configuration请求中包含的header字段以及ID路由字段之外，配置请求还包含以下字段（请参见 Figure 2-20)：

  • Register Number[5:0]

  • Extended Register Number[3:0]

Figure 2-20 Request Header Format for Configuration Transactions

• Configuration Request 必须遵守以下限制：

  • TC[2:0］必须等于000b。

  • LN字段对Configuration Request 没用，必须设置为保留值。

  • TH字段对Configuration Request没用，必须设置为保留值。

  • Attr[2］为保留值。

  • Attr[1:0］必须等于00b。

  • AT[1:0］必须等于00b。

  • Length[9:0］必须等于0000000001b。

  • Last DW BE[3:0］必须等于0000b。

接收者可以选择检查是否违反了这些规则（但不能检查保留位）。这些检查是独立可选的（请参见Section 6.2.3.4）。如果实施这些检查的接收方确定TLP违反了这些规则，则该TLP是Malformed TLP。

	 - 如果实现，这将报告的与接收端口相关的错误（请参见Section 6.2）。

消息信号中断（MSI/MSI-X）机制使用 Memory Write Request 来表示中断消息（请参见Section 6.1.4）。用于MSI/MSI-X事务的请求格式与上面定义的Memory Write Request格式相同，在排序，流控制和数据完整性方面，MSI/MSI-X请求与Memory Write 没有区别。

2.2.7.1 TPH Rules

• 为TPH定义了两种格式。所有提供TPH的请求都必须使用Baseline TPH format（见Figure 2-20和Figure 2-21）。带有Optional TPH TLP Prefix的格式扩展了TPH字段（请参见Figure 2-19)，以为Steering Tag(ST）字段提供其他字段。

Figure 2-21 TPH TLP Prefix

• Optional TPH TLP Prefix用于扩展TPH字段。
  • 通过解码byte 0可以确定TPH TLP Prefix的存在 (byte0[7:5]=111∼b，表示当前TLP为一个TLP Prefix）。

Table 2-13 TPH TLP Prefix

Bit Mapping

• 对于以内存空间为目标的请求，TH字段值为1b表示TLP header中存在TPH和可选的TPH TLP Prefix。

  • 必须将提供TPH的请求的TH字段置1。

  • 对于带有TPH TLP Prefix的请求，必须将TH字段置1。

  • 当TH字段为0，必须将PH字段置为保留值。

  • 对于其他Request,TH位和PH字段不适用并为保留值。

• Processing Hints (PH）字段映射如Figure 2-22,Figure 2-23和Table 2-14所示。

Figure 2-22 Location of PH[1:0] in a 4 DW Request Header

Figure 2-23 Location of PH[1:0] in a 3 DW Request Header

Table 2-14 Location of PH[1:0] in TLP

Header

• PH[1:0］字段提供有关数据访问模式的信息，Table 2-15给出定义。

Table 2-15 Processing Hint Encoding

• 如Figure 2-24, Figure 2-25和 Table 2-16所示，Steering Tag(ST）字段映射到TLP
  header。
  

Figure 2-25 Location of ST[7:0] in Memory Read and AtomicOp Request Headers

Table 2-16 Location of ST[7:0] in TLP Headers

• ST[7:0］字段携带 Steering Tag值。

  • 全零值表示无Steering Tag preference。

  • 总共提供255个唯一的Steering Tag值。

• 不支持TPHCompleter或路由能力并且接收到TH位为1的事务的Function需要忽略TH字段，并以与TH没有设置为1的相同事务类型的请求相同的方式处理请求。

2.2.8 Message Request Rules

本规范定义了一下Message类型：

• INTx Interrupt Signaling
• Power Management
• Error Signaling
• Locked Transaction Support
• Slot Power Limit Support
• Vendor-Defined Messages
• Latency Tolerance Reporting (LTR) Messages
• Optimized Buffer Flush/Fill (OBFF) Messages
• Device Readiness Status (DRS) Messages
• Function Readiness Status (FRS) Messages
• Precision Time Measurement (PPTM) Messages

以下规则适用于所有Message Request。还为每种特定的Message Request 指定了规则。

• 除了公共的header字段之外，所有Message Request都包括以下字段（请参见 Figure 2-26)：

  • Requester ID[15:0］和Tag[9:0]，组成了Transaction ID。

  • Message Code[7:0]，指明了请求包含的特定消息。

Figure 2-26 Message Request Header

• 除Vendor_Defined Message（可以使用Msg或MsgD）和Set_Slot_Power_Limit
  Message（使用MsgD）外，所有 Message Request 均使用Msg Type字段编码。
• 消息代码字段必须完整解码（不允许使用消息别名）。
• 除非特别指出，否则Attr[2］字段不是保留值。
• 除非另有说明，否则Attr[1:0］字段为保留值。
• LN不适用于消息请求，并且该位为保留值。
• 除非另有说明，TH不适用于消息请求，并且该位为保留值。
• AT[1:0］必须为00b。接收者不需要进行检查。
• 除非另有说明，byte8至byte 15为保留值。
• 消息请求是posted 请求，不需要Completion。
• 消息请求遵循与内存写请求相同的排序规则。

许多类型的消息（包括Vendor-Defined Message）可能在non-DO状态下可用，并且强烈建议当Port的Bridge Function处于D1，D2和D3Hot中时，对Port的消息处理应与在DO时相同。强烈建议Type 0 Function支持在non-DO状态下生成和接收消息。

除了地址路由和ID路由外，消息还支持其他几种路由机制。这些机制被称为“隐式路由”，因为没有地址或ID指定目的地，而是路由类型隐含了目的地。以下给出了消息路由机制的规则：

• 使用Type字段的r[2:0］子字段确定消息路由。
  • 消息路由的编码如Table 2-17。
  • 在以下各节中为每个消息定义允许的值。

Table 2-17 Message Routing

注15：除非另有说明，例如Vendor_Defined Message这些字节可能会自己定义。

注16：本规范没有定义任何使用地址路由的消息。

注17：此路由类型仅用于PME_TO_Ack，在Section 5.3.3.2.1中进行了描述。

2.2.8.1 INTx Interrupt Signaling - Rules

MSI或MSI-X是PCI Express中首选的中断信令机制（请参见Section 6.1）。但是，在某些系统中，可能有一些功能不支持MSI或MSI-X机制。在无法使用MSI或MSI-X机制的情况下，可以使用INTx虚拟中断线信令机制来支持 Legacy Endpoint 和PCI Express/PCI(-X)Bridge。Switch必须支持此机制。以下规则适用于INTx中断信令机制：

• INTx机制使用八个不同的消息（请参见Table 2-18）。
• Assert_INTx/Deassert_INTx Message 不包含数据载荷（TLP Type is Msg）。
• Length 字段为保留值。
• 对于Assert_INTx/Deassert_INTx Message,Requester ID的Function Number字段为0。请注意，对于non-ARI和ARI的Requester ID,Function Number字段的比特数不同。
• Assert_INTx/Deassert_INTx Message只会由Upstream Port发送。
• 接收者可以选择检查是否违反此规则。如果执行此检查的接收方确定Assert_INTx/Deassert_INTx违反了此规则，则它必须将TLP视为Malformed TLP。
• Assert_INTx/Deassert_INTx Message使用TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为Malformed TLP。

Table 2-18 INTx Mechanism Messages

注18： RC=RC; Sw=Switch (only used with “Link” routing); Ep=Endpoint ; Br=PCIExpress (primary) to PCI/PCI-X (secondary)Bridge r=Supports as Receiver ; t=Supports as Transmitter Assert_INTx/Deassert_INTx Message 构成每个称为A、B、C和D的传统PCI中断的四个“虚拟线”。以下规则描述了这些虚拟线的操作：

• 每个链路两端的组件必须使用Assert/Deassert Message
  来跟踪四条虚拟线的逻辑状态，以分别表示每条相应虚拟线的有效和无效的变化。

  • Assert_INTx表示INTx (x=A、B、C或D）虚拟线的有效状态。

  • Deassert_INTx表示INTx(x=A、B、C或D）虚拟线的无效状态。

• 当INTx虚拟线的本地逻辑状态在上游端口更改时，该端口必须使用适当的Assert_INTx或Deassert_INTx消息将此状态的更改传达给同一链路另一侧的下游端口。

注意：重复的Assert_INTx/Deassert_INTx Message 无效，但不是错误。

• 当Command寄存器的 Interrupt Disable字段（Section7.5.1.1）设置为1b时，INTx中断信令被禁用。
  • 必须通过发送Deassert_INTx消息来取消任何有效的INTx虚拟线。
• 虚拟和实际的PCI to PCI Bridge 必须根据桥接器次级侧上设备的Device Number
  映射在桥接器次级侧上跟踪的虚拟线，如Table 2-19所示。
• Switch必须为每个下游端口独立跟踪四根虚拟线的状态，并在其上游端口上显示一组“折叠”的虚拟线。
• 如果下游端口变为DL_Down状态，则必须把与该端口关联的INTx虚拟线路置为无效，并且相应更新上游端口虚拟线路状态。
  • 如果这导致取消任何上游INTx虚拟线有效，则必须由上游端口发送Deassert_INTx消息。
• RC必须针对其每个下游端口独立跟踪四根INTx虚拟线的状态，并将这些虚拟信号映射到系统中断资源。
  • 此映射的详细信息是特定于系统实现的。
• 如果RC的下游端口进入 DLown状态，则必须把与该端口关联的INTx虚拟线路置为无效，并且必须丢弃任何关联的系统中断资源请求。

Table 2-19 Bridge Mapping for INTx Virtual Wires

注19:Assert_INTx/Deassert_INTx Message的 Requester ID将与该链路上的消息的发送方相对应，而不必与中断的原始源相对应。

IMPLEMENTATION NOTE

System Interrupt Mapping

请注意，系统软件（包括BIOS和操作系统）需要理解系统整个拓扑结构（包括分层连接的Switch和从属的PCI Express/PCI Bridge）中的传统中断（INTx机制）的重新映射，以建立PCI Express设备中断和系统中断控制器中的相关中断资源的关联。Table 2-20所描述的重新映射应用于每个Switch的层次结构。另外，PCI Express/PCI Bridge和PCI/PCI Bridge执行类似的映射功能。

IMPLEMENTATION NOTE

Virtual Wire Mapping for INTx Interrupts From ARI Devices

ARI设备的隐含设备号为0。当ARI感知软件（包括BIOS和操作系统）在ARI设备正上方的下游端口中启用ARI转发以访问其扩展功能时，软件必须理解下游端口，将使用设备编号0来表示ARI设备所有功能产生的INTx中断的虚拟线路映射。如果不支持ARI的软件尝试确定扩展功能的虚拟线路映射，则可以通过检查传统的“设备编号”字段并将其查找为非0来提出错误的映射。

2.2.8.2 Power Management Messages

这些消息用于支持PCI Express电源管理，这将在Section5中详细介绍。以下规则定义了电源管理消息：

• Table 2-20给出了所有的电源管理消息。
• 电源管理消息不包括数据有效负载（TLP类型为Msg）。
• Length字段保留。
• 对于PM_Active_State_Nak消息，Requester ID中的Function Number字段必须包含发送该消息的下游端口的 Function Number，或者为000b，以便与该规范的早期版本兼容。
• 对于PME_TO_Ack消息，Requester ID中的 Function Number字段保留，否则，为了与本规范的早期版本兼容，必须包含与上游端口关联的Function之一的Function Number。请注意，对于non-ARI和ARI的Requester ID, Function Number的比特数不同。
• 电源管理消息必须使用TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为Malformed TLP。

Table 2-20 Power Management Messages

2.2.8.3 Error Signaling Messages

错误信令消息用于信令发生在特定事务上的错误和不一定与特定事务相关联的错误。这些消息由检测到错误的设备发出。

• Table 2-21给出了所有的错误信令消息。
• 错误信令消息不包括数据有效负载（TLP类型为Msg）。
• Length字段保留。
• 对于错误信令消息，Requester ID中的Function Number字段必须指示哪个Function正在发出错误信令。请注意，对于non-ARI 和ARI的Requester ID,Function Number的比特数不同。
• 错误信令消息必须使用TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为Malformed TLP。

Table 2-21 Error Signaling Messages

消息的发起者由消息头的Requester ID标识。RC将这些错误消息转换为平台级事件。有关这些消息的用法，请参阅Section6.2。

• ERR_COR Message 在消息头中有一个ERR_COR Subclass(ECS）字段，该字段使不同的子类能够相互区分。参见Figure2-27。ERR_NONFATAL和ERR_FATAL消息没有ECS字段。

Figure 2-27 ERR_COR Message

• ERR_COR Subclass(ECS）字段的编码如 Table 2-22所示，指示ERR_COR消息子类。

Table 2-22 ERR_COR Subclass (ECS) Field Encodings

2.2.8.4 Locked Transactions Support

Unlock Message 用于支持Lock Transaction的处理过程。有关Lock Transaction处理过程的详细信息，请参见Section 6.5。以下规则适用于Unlock Message的构造：

• Table 2-23 给出了Unlock Message的定义。
• Unlock Message 不包括数据有效负载（TLP类型为Msg）。
• Length字段保留。
• 对于Unlock Message,Requester ID中的Function Number字段为保留值。
• Unlock Message必须使用TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为Malformed TLP。

Table 2-23 Unlock Message

2.2.8.5 Slot Power Limit Support

此消息用于将插槽电源限制值从RC或Switch的下游端口传送到该链路另一侧设备的（Endpoint、Switch或PCI Express-PCI Bridge Function）的上游端口。

• Table 2-24定义了Set_Slot_Power_Limit Message。
• Set_Slot_Power_Limit Message 包含一个1DW的有效数据载荷（TLP Type is MsgD）。
• Set_Slot_Power_Limit Message使用TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为 Malformed TLP。

Table 2-24 Set_Slot_Power_Limit Message

Set_Slot_Power_Limit Message 包括一个DW数据有效载荷。数据有效载荷是从下游端口的Slot Capabilities 寄存器复制的，并写入链路另一侧的上游端口的Device Capabilities寄存器。数据有效载荷的byte 1[1:0］映射到Slot Power Limit Scale字段，byte 0[7:0］映射到Slot Power Limit Value 字段。数据有效载荷的byte 3[7:0],byte 2[7:0］和byte 1[7:2］必须由发送器设置为全0，且接收器要忽略这些值。当发生以下事件之一时，此消息必须由RC或Switch的下游端口自动发送：

• 当数据链路层报告DL_Up状态后，如果发送配置写访问Slot Capabilitie 寄存器（请参见 Section 7.5.3.9）。
• 链路从non-DL_Up状态转换为DL_Up状态的任何传输（请参阅Section 2.9.2）。如果尚未初始化 Slot Capabilitie 寄存器，则此传输是可选的。

接收Set_Slot_Power_Limit 消息的链路另一端的组件（Endpoint、Switch或PCI Express-PCI Bridge Function）必须将数据有效负载中的值复制到与组件的上游端口关联的Device Capabilities寄存器中。PCI Express组件专门用于在系统平面上集成（例如，系统板），以及集成在卡／模块上的组件，其中整个卡／模块的功耗低于指定的最低功耗限制。卡／模块的外形尺寸（在相应的外形尺寸规格中定义）被允许在Device Capabilities 寄存器的Slot Power Limit Scale 和 Slot Power Limit Value 字段中硬接线为全0的值，并且不需要复制 Set_Slot_Power有效负载的值到该寄存器中。

有关电源限制控制机制的更多详细信息，请参见Section 6.9。

2.2.8.6 Vendor_Defined Messages

Vendor_Defined Message 允许扩展PCI Express消息传递功能，既可以作为PCI Express 规范的常规扩展，也可以作为特定于供应商的扩展。尽管本规范的未来修订版可能会使用此机制来定义新的消息（请参阅下文），但本文档未特别涵盖此类扩展。本节通常定义与这些消息关联的规则。

• Vendor_Defined Message (Table 2-25）的header 格式如 Figure 2-25。

  • Requester ID是实现相关的。

  • 如果使用ID路由，则byte8和byte9构成目标ID的16字段。

    • 否则，这些字节将保留。

  • byte 10和byte 11构成了定义消息的供应商的 PCI-SIG定义的Vendor ID的16比特字段。

  • byte 12至byte 15可用于供应商定义。

Table 2-25 Vendor_Defined Messages

Note 1:Endpoint/RC/Bridge的传输是特定于实现的。Switch必须使用Routing[2:0］字段值000b,010b和011b转发接收到的消息。

Figure 2-28 Header for Vendor-Defined Messages

• Vendor_Defined Message包含数据有效载荷（如果不包括数据有效载荷，则TLP类型为Msg；如果包括数据有效载荷，则为MsgD）。
• Vendor_Defined Message的Attr[1:0］和Attr[2］字段值为保留值。
  • 由不同供应商或PCI-SIG定义的消息由Vendor ID字段中的值来区分。
  • 由特定供应商定义的消息的进一步区分超出了本文档的范围。
• 对特定供应商定义的消息的支持是特定于实现的，超出了本文档的范围。
• 完成者会丢弃他们不打算接收的Vendor_Defined Type 1 Message-这不是错误。
• 完成者将收到不支持的Vendor_Defined Type 0 Message 作为Unsupported Request进行处理，并且根据Section 6.2报告错误。

PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0定义了 Vendor_Defined Message的其他要求，这些消息旨在与PCI-X Device ID Message 互操作。这包括对Tag[7:0］字段和Length[9:0］字段的内容的限制，以及对消息头的byte 12到byte 15的特定使用。仅在PCI Express环境中使用的Vendor_Defined Message（即不旨在解决PCI Express to PCI/PCI-X Bridge 后面的目标）不受其他规则的约束。有关详细信息，请参阅PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0。

2.2.8.6.1 PCI-SIG-Defined VDMs

PCI-SIG定义的VDM是使用PCI-SIG® Vendor ID(0001h）的Vendor-Defined Type 1 Message。作为 Vendor-Defined Type 1 Message，如果完成者未实现，则每个消息都会被完成者静默丢弃。

除了其他Vendor-Defined Type 1 Message的规则之外，以下规则适用于PCI-SIG-Defined VDM的格式：

• PCI-SIG-Defined VDM的Header的结构如Figure 2-29所示。
• Requester ID字段必须填充为Requester对应的值。
• Message Code 必须为01111111b。
• Vendor ID必须为0001h，已分配给PCI-SIG。
• Subtype字段区分特定的PCI-SIG定义的VDM。有关PCI-SIG-Defined VDM的列表，请参见Appendix F。

Figure 2-29 Header for PCI-SIG-Defined VDMS

2.2.8.6.2 LN Messages

LN协议（见 Section 6.21）定义LN Message，即PCI SIG定义的 VDM∘每条消息的有效负载通常包含已更新或逐出的已注册 cacheline 的64位地址。单个64位地址格式同时用于64位和32位地址。由于每个LN Message都是一个Vendor-Defined Type 1 Message，因此如果完成程序无法识别消息，则完成者会自动丢弃该消息。

可以使用基于ID的路由将LN Message定向到单个Endpoint，或将其广播到给定Root Port下的所有设备。一个广播LN Message 是否发送到RC中的所有Root Port是特定于实现的。

除了其他PCI-SIG定义的VDM的规则之外，以下规则适用于LN Message的构成：

• Table 2-27和Figure 2-30定义了LN Message。
• 每个Message必须包含2-DW的数据负载。
• Fmt字段必须为011b(4DW，带数据）。
• TLP Type必须为MsgD。
• Length字段必须为2。
• TC[2:0］字段必须为000b。
• Attr[2], 即ID-Based Ordering(IDO)，不能为保留字段。
• Attr[1]，即 Relaxed Ordering(RO)，不能为保留字段。
• Attr[0]，即No Snoop字段，必须为保留字段。
• LN字段为保留字段（相反，必须为LN Read,LN Write和LN Completion设置LN字段）。
• Tag字段为保留字段。
• 如果LN Message是一个广播版本，则Destination ID字段为保留字段。
• Subtype字段必须为00b。
• 如果对系统有效的cacheline大小为128字节，则Cacheline Address 中的Bit 6必须为0。对于接收LN Message的Lightweight Notification Requester (LNR)，如果LNR Control寄存器中的LNR CLS字段置1，则将LNR配置为128字节cacheline，则LNR 必须忽略CachelineAddress中Bit 6的值。
• Notification Reason(NR）字段的编码如 Table 2-26所示，指示发送LN Message的特定原因。这些编码适用于LN Message 的定向和广播版本。

Table 2-26 Notification Reason (NR) Field Encodings

Table 2-27 LN Messages

Figure 2-30 LN Message

2.2.8.6.3 Device Readiness Status (DRS) Message

设备就绪状态（DRS）协议（请参阅Section 6.23.1）使用PCI-SIG-Defined VDM 机制（请参阅Section 2.2.8.6.1）。DRS Message 是没有数据负载的PCI-SIG-Defined VDM(Vendor-Defined Type 1 Message）。

除了其他PCI-SIG-Defined VDM的规则之外，以下规则适用于DRS Message 的构成：

• Table 2-28和Figure 2-31定义了DRS Message。
• TLP Type必须为Msg。
• TC[2:0］字段必须为000b。
• Attr[2:0］为保留字段。
• Tag字段为保留字段。
• Subtype字段为08h。
• Message Routing 字段必须设置为100b-Local-即在接收端终止。

接收者可以选择检查是否违反了这些规则（但不能检查保留位）。这些检查是独立可选的（请参见Section 6.2.3.4）。如果执行这些检查的接收方确定TLP违反了这些规则，则该TLP是Malformed TLP。

• 如果执行此检查，则这是与接收端口相关的报告错误（请参阅Section 6.2）。

Table 2-28 DRS Message

Figure 2-31 DRS Message

2.2.8.6.4 Function Readiness Status Message (FRS Message)

功能就绪状态（FRS）协议（请参阅Section 6.23.2）使用PCI-SIG-Defined VDM机制（请参阅Section 2.2.8.6.1）。FRS Message 是没有数据负载的PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message）。

除了其他PCI-SIG-Defined VDM的规则之外，以下规则适用于FRS消息的构成：

• Table 2-29和Figure 2-32定义了FRS Message。
• TLP Type必须为Msg。
• TC[2:0］字段必须为000b。
• Attr[2:0］为保留字段。
• Tag字段为保留字段。
• Subtype字段为09h。
• FRS Reason[3:0］字段指示生成FRS Message的原因：

  • 0001b: DRS Message Received

    • 由Message Requester ID指示的下游端口接收到DRS Message，并且在Link Control寄存器中将DRS Signaling Control 字段设置为DRS to FRS Signaling Enabled。

  • 0010b: D3Hot to D0 Transition Completed

    • 从D3Hot到DO的转换已经完成，并且由Message Requester ID 指示的Function现在已准备就绪，并且已根据No_Soft_Reset位的设置返回到DOuninitialized或DOactive状态（请参见Section7.5.2.2）。

  • 0011b: FLR Completed

    • FLR已完成，并且Message Requester ID 指示的 Function 现在已 Configuration-Ready。

  • 1000b: VF Enabled

    • Message Requester ID 指示了一个Physical Function(PF)-与该PF关联的所有Virtual
      Function(VF）现在都已Configuration-Ready。

  • 1001b: VF Disabled

    • Message Requester ID 指示了一个 Physical Function(PF)-与该PF关联的所有Virtual
      Function(VF）现在都已被禁止，且PF中的SR-IOV data structure 可能不能访问。

  • Others:

    • 所有其他值保留。

·Message Routing字段必须清为000b-即路由到RC。

接收者可以选择检查是否违反了这些规则（但不能检查保留位）。这些检查是独立可选的（请参见Section 6.2.3.4）。如果执行这些检查的接收方确定TLP违反了这些规则，则该TLP是一个Malformed TLP。

• 如果执行此检查，则这是与接收端口相关的报告错误（请参阅Section 6.2）。

Table 2-29 FRS Message

Figure 2-32 FRS Message

2.2.8.6.5 Hierarchy ID Message

Hierarchy ID Message 使用PCI-SIG-Defined VDM机制（请参见Section 2.2.8.6.1）。Hierarchy ID Message是携带有效负载（MsgD）的PCI-SIG-Defined VDM(Vendor-Defined Type 1 Message）。

除了其他PCI-SIG-Defined VDM的规则之外，以下规则适用于Hierarchy ID Message的形成：

• Table 2-30和Figure 2-33定义了 Hierarchy ID Message。
• TLP Type必须为MsgD。
• 每个Message 必须包含4-DW的数据负载。
• Length字段必须为4。
• TC[2:0］字段必须为000b。
• Attr[2:0］为保留字段。
• Tag字段为保留字段。
• Subtype字段必须为01b。
• Message Routing 字段必须为011b-即RC发起的广播。

接收者可以选择检查是否违反了这些规则（但不能检查保留位）。这些检查是独立可选的（请参见Section 6.2.3.4）。如果执行这些检查的接收方确定TLP违反了这些规则，则该TLP是一个Malformed TLP。

• 如果执行此检查，则这是与接收端口相关的报告错误（请参阅Section 6.2）。

每个Hierarchy ID Message 的有效负载包含System GUID的低128位。

有关Hierarchy ID、GUID Authority ID和 System GUID字段的详细信息，请参见Section 6.26。

Table 2-30 Hierarchy ID Message

Figure 2-33 Hierarchy ID Message

2.2.8.7 Ignored Messages

Table 2-31中列出的消息以前用于不再支持的机制（热插拔信令）。强烈建议发送者不要发送这些消息，但是如果实现了这些消息的发送，则它必须符合本规范1.0a版本的要求。

强烈建议接收者忽略这些消息的接收，但允许接收者按照本规范1.0a版的要求处理这些消息。

Table 2-31中列出的被忽略的消息由接收方处理如下：

• 物理层和数据链路层必须像处理任何其他TLP一样处理这些消息。
• 事务层必须考虑流量控制，但不能对这些消息采取任何其他措施。

Table 2-31 Ignored Messages

2.2.8.8 Latency Tolerance Reporting (LTR) Message

LTR Message 可选地用于报告有关其读／写服务等待时间容限的设备行为。有关LTR的详细信息，请参见Section 6.18。以下规则适用于LTR Message的构造：

• Table 2-32定义了LTR Message。
• LTR Message 没有数据负载（the TLP Type is Msg）。
• Length字段为保留值。
• LTR Message 使用 TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为Malformed TLP。

Table 2-32 LTR Message

Note 1：对LTR的支持是可选的。支持LTR的Function必须实现 Chapter 7中描述的报告和启用机制。

Figure 2-34 LTR Message

2.2.8.9 Optimized Buffer Flush/Fill (OBFF) Message

OBFF Message 可选择用于向Endpoint报告平台主要资源状态。该机制在Section 6.19中有详细描述。

以下规则适用于OBFF消息的构造：

• Table 2-33定义了OBFF Message。
• OBFF Message 没有数据负载（the TLP Type is Msg）。
• Length字段为保留值。
• Requester ID必须设置为发送器的端口ID。
• OBFF Message 使用TCO。接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为Malformed TLP。

Table 2-33 OBFF Message

注1：对OBFF的支持是可选的。支持OBFF的Function必须实现 Chapter 7中描述的报告和启用机制。

Figure 2-35 OBFF Message

2.2.8.10 Precision Time Measurement (PTM) Messages

Table 2-34定义了 PTM Message。

• PTM Request Message 和 PTM Response Message的TLP类型为Msg，并且不能包含有效数据载荷。长度字段处理为保留。

  • Figure 2-36说明了PTM Request Message 和 PTM Response Message的格式。

• PTM ResponseD Message的TLP类型为MsgD，并且必须在TLP Header的 Byte 8到Byte15中包括一个64位的PTM Master Time字段和一个包含32位的Propagation Delay 字段的1DW有效数据载荷。

  • Figure 2-37说明了 PTM ResponseD Message的格式。

  • 有关如何填充PTM ResponseD Message的详细信息，请参见Section 6.22.3.2。

• 必须将Requester ID设置为发送端口的ID。

PTM对话定义为由PTM Request和相应的 PTM Response Message 或PTM ResponseD Message 组成的匹配消息对。

• PTM消息必须使用默认的业务类别指示符（TCO）。实现PTM的接收者必须检查是否违反此规则。如果接收方确定TLP违反此规则，则它必须将TLP视为一个 Malformed TLP。
  • 这是一个与接收端口相关的报告错误（参见Section 6.2）。

Table 2-34 Precision Time Measurement Messages

Figure 2-36 PTM Request/Response Message

Figure 2-37 PTM ResponseD Message (4 DW header and 1 DW payload)

2.2.9 Completion Rules

所有的Read、Non-Posted Write和AtomicOp Request 都需要返回一个Completion。Completion 有两种类型：一种带数据负载的，一种不带数据负载的。以下各节定义了Completion header中每个字段的规则。

• Completion使用ID路由，使用3DW头。

  • 注意，routing ID字段直接对应相应请求者的 Requester ID。因此，对于Completion，这些字段将统称为Requester ID，而不是用于ID路由的不同字段。

• 除了所有TLP中包含的Header字段和ID路由字段之外，Completion还包含以下其他字段（请参阅Figure 2-38)：

  • Completer ID[15:0]-Completer的 ID。

  • Completion Status[2:0]-见 Table 2-35的描述。

    • 在Section 2.3.1 中描述 Completion Status[2:0］值的规则。

  • BCM-Byte Count Modified：此位不得由PCI Express Completer 设置，只能由PCI-X completer 设置。

  • Byte Count[11:0]-请求的剩余字节数。

    • 字节计数值指定为二进制数，其中000000000001b表示剩余1字节，11111111
      1111b表示剩余4095个字节，而000000000000b表示剩余4096个字节。

    • 对于Memory Read Completion, Byte Count[11:0］要遵循Section 2.3.1.1的规则。

    • 对于AtomicOp Completion,Byte Count的值等于相关的AtomicOp操作数的size。

    • 对于其他的Completion,Byte Count等于4。

• Tag[9:0]-结合 Requester ID 字段，一起组成Transaction ID。

• Lower Address[6:0]-Completion 起始字节的低字节地址。

    - 对于Memory Read Completion，此字段中的值是随Completion返回的数据的第一个有效字节的地址（请参见Section2.3.1.1中的规则）。
  
    - 对于AtomicOp Completion, Lower Address 字段值为保留值。
  
    - 对于所有其他的Completion类型，此字段均设置为全0。 接收者可以选择检查是否违反此规则。有关详细信息，请参见Section2.3.2。
  

Figure 2-38 Completion Header Format

Table 2-35 Completion Status Field Values

• Completer ID[15:0］是一个16位值，对于层次结构中的每个PCI Express的FUnction都是唯一的（请参见Figure 2-39和 Figure 2-40)。

Figure 2-39 (Non-ARI) Completer ID Figure 2-40 ARI Completer ID

• Function 必须能捕获Type 0 Configuration Write Request中的Bus和 Device Number，并把这些值用于Completion的Completer ID。
  • 如果Function 必须在发送设备 Configuration Write Request 之前生成Completion，则必须在Bus Number 和 Device Number字段中输入0。
  • 请注意，Bus Number和 Device Number 可能会在运行时更改，因此有必要在每个Configuration Write Request 中重新捕获此信息。
  • 例外：可以通过特定于实现的方式将Bus Number分配给RC中的设备。

注意：对于ARI设备，Function只需要捕获Bus Number。ARI设备可以按设备或按功能保留捕获的Bus Number。参见Section 2.2.6.2。

注意：一个ARI设备的Completer ID 不包括 Device Number字段。参见 Section 2.2.4.2。

注意：一个ARI设备的Completer ID其Function number字段为8 bit。

• 在某些情况下，multi-Function 设备可能会生成具有UR状态的Completion，而不会将该Completion与设备内的特定Function 相关联-在这种情况下，Function Number字段是保留的。
  • 示例：multi-Function 设备收到的 Read Request的目标不是与该设备任何Function相关的任何资源，该设备会生成具有UR状态的Completion，并在Completer ID的Function Number字段中将其值设置为全0。
• Completion header 必须为Requester ID提供同样的值，Tag和Traffic Class 提供与相应Request header 中相同的值。
• Completion Header 必须为Attribute 提供与相应Request header中相同的值，除非以下操作明确允许：
  • 当使用了IDO时（请参阅Section 2.2.6.4）。
  • 当在Translation Completion中使用了RO时（参阅Section 10.2.3）。
• 如果完成者是LN Completer(LNC)，并且目标存储区支持registration，则适用以下规则；否则，LN位必须清零。
  • 如果 Completion Status 为Successful Completion 并且关联的请求是LN Read，则必须将LN位置1。
  • 否则LN必须设置为 0。
• Completion的TH字段设置为保留值。
• 在完成设备的软件初始化和配置之前（至少使用一个Configuration Write Request),Completer ID字段没有意义，对于这种情况，请求者必须忽略Completer ID字段中返回的值。
• 包含数据的Completion 必须指定该Completion中返回的实际数据量，并且必须包含指定的数据量。
  • 包含比Length字段中指定的更多或更少的数据的TLP会形成错误，并且生成的TLP是Malformed TLP。

注意：这只是一般规则的一个特殊情况，要求TLP数据有效载荷长度与Length字段中的值匹配。

2.2.10 TLP Prefix Rules

以下规则应用于包含一个TLP Prefix的任何 TLP：

• 对于任何TLP,TLP byte 0中的Fmt[2:0］字段值为100b表示存在TLP Prefix，而Type[4］字段表示TLP Prefix的类型。

  • Type[4]=0∼b，为一个Local TLP Prefix。

  • Type[4]=0∼b，为一个End-End TLP Prefix。

• TLP的byte1到byte3的格式根据TLP Prefix的类型来定义。

• 包含TLP Prefix的TLP有一个潜在的TLP Header。收到的TLP如果违反了此规则，则被视为一个Malformed TLP。相关的接收端口会报一个错误（see Section 6.2）。

• 允许一个TLP与多个不同类型的TLP Prefix。

  • 当TLP中包含 Local TLP Prefix和 End-End TLP Prefix的组合时，要求所有Local TLP Prefix出现任何 End-End TLP Prefix之前。收到的TLP如果违反了此规则，则被视为一个Malformed TLP。相关的接收端口会报一个错误（see Section 6.2）。

• 每个TLP Prefix的大小为1DW。TLP Prefix可以重复以提供更多数据。

• 如果Fmt和Type字段定义了一个Local TLP Prefix，则按Local TLP Prefix的规则处理（see Section 2.2.10.1）。

• ·如果Fmt和Type字段定义了一个End-EndTLP Prefix，则按End-End TLP Prefix的规则处理（see Section 2.2.10.2）。

2.2.10.1 Local TLP Prefix Processing

以下规则应用于Local TLP Prefix：

• Type字段的子字段L[3:0］定义了Local TLP Prefix的类型。

  • Type[4］必须为0b。

  • L[3:0］定义如 Table 2-36。

Table 2-36 Local TLP Prefix Types

• 不同的Local TLP Prefix类型有特定的大小、路由方式和流控机制。
• 接收器收到的TLP的Local TLP Prefix 如果是不支持的类型就会触发一个错误。如果Extended Fmt Field Supported字段设置为1b，则除非另有明确规定，否则违反此规则的TLP将被视为Malformed TLP。相关的接收端口会报一个错误（see Section 6.2）。如果 Extended Fmt Field Supported字段设置为0b，则行为是特定于设备的。
• TLP可能会受ECRC保护，但其Local TLP Prefix不会受ECRC保护。

2.2.10.1.1 Vendor Defined Local TLP Prefix

如Table 2-36所述，类型VendPrefixLO和VendPrefixL1保留用作供应商定义的 Local TLP Prefix。为了最大程度地提高互操作性和灵活性，将以下规则应用于此类前缀：

• 除非已明确启用（使用供应商特定的机制），否则组件不得发送包含Vendor Defined Local TLP Prefixe的TLP。
• 支持任何使用 Vendor Defined Local TLP Prefixe的组件都必须支持3bit的Fmt字段的定义，并设置了Extended Fmt Field Supported字段（请参见Section 7.5.3.15）。
• 建议组件是可配置的（使用特定于供应商的机制），以便可以使用两种Vendor Defined Local TLP Prefixe编码中的任何一种来发送所有供应商定义的前缀。这样的配置不必是对称的（例如，链路的每一端都可以使用不同的编码来发送相同的前缀）。

2.2.10.2 End-End TLP Prefix Processing

• Type字段的子字段E[3:0］定义了End-End TLP Prefix的类型。
  • Type[4］必须为1b。
  • E[3:0］定义如Table 2-37。

Table 2-37 End-End TLP Prefix Types

• 一个TLP允许的End-End TLP Prefix最大数目为4。
  • 支持TLP Prefix的接收方必须检查此规则。如果接收方确定TLP违反此规则，则该TLP为Malformed TLP。这将报告与接收端口相关的错误（请参见Section 6.2）。
• End-End TLP Prefix的存在不会改变TLP的路由。TLP是根据Section 2.2.4中介绍的路由规则进行路由的。
• Function 通过Device Capabilities 2 寄存器中的MMax End-End TLP Prefixes字段指示它们支持多少个End-End TLP Prefix（请参见Section 7.5.3.15)。
  • 对于Root Port，允许 Max End-End TLP Prefixes字段返回一个值，该值指示支持的End-End TLP Prefix少于Root Port硬件实际实现的数量。但是，错误处理语义仍然必须基于字段中包含的值。如果收到的TLP包含的End-End TLP Prefix多于Root Port支持的TLP，则必须按以下方式处理。建议将Request 作为Unsupported Request处理，否则，必须将它们作为Malformed TLP处理。建议将Completion 作为 Unexpected Completion 处理，否则，必须将它们作为Malformed TLP 处理。对于由Ingress Port接收的TLP，这是与Ingress Port相关联的报告错误。对于内部接收的TLP要从Egress Port发送出去，这将报告与Egress Port相关的错误。请参阅Section 6.2。
  • 对于所有其他Function，接收到的TLP包含的End-End TLP Prefix多于Function所支持的TLP，则必须将其视为MMalformed TLP。这将报告的与接收端口相关的错误（请参见 Section 6.2）。

按照 Section 6.2.4.4节的规定进行AER日志记录（如果支持）。

• 如果 End-End TLP Prefix Supported 字段设置为1b，则Switch必须支持最多4个End-End TLP Prefix的TLP转发。

• End-End TLP Prefix Supported 字段设置为1b的各种Root Port允许设置不同的 Max End-End TLP Prefixes值。

• 如果TLP支持ECRC保护，则其所有End-End TLP Prefix 也收ECRC保护。

• 接收器收到的TLP的End-End TLP Prefix如果是不支持的类型就会触发一个错误。违反此规则的TLP将被视为Malformed TLP。相关的接收端口会报一个错误（see Section 6.2）。

• 软件应确保不将包含End-End TLP Prefix的TLP发送到不支持它们的组件。Extended Fmt Field Supported字段为0b的组件可能会错误解释包含TLP Prefix的TLP。

• 如果上游端口的一个Function把End-End TLP Prefix Supported字段设置为1b，则该上游端口的所有Function必须处理接收到的请求，如果该请求包含不支持的End-End TLP Prefix，则该请求作为Unsupported Request。相关的接收端口会报一个错误（see Section 6.2）。

• 如果上游端口的一个Function把End-End TLP Prefix Supported字段设置为1b，则该上游端口的所有Function必须处理接收到的Completion，如果该Completion包含不支持的End-End TLP Prefix，则该Completion 作为 Unsupported Completion。相关的接收端口会报一个错误（see Section 6.2）。

• 对于路由元素，每个Egress Port中的 End-End TLP Prefix Blocking 字段确定是否可以通过该Egress Port 发送包含 End-End TLP Prefix的TLP（请参见 Section 7.5.3.16）。如果转发被阻止，则整个TLP将被丢弃，并报告一个TLP Prefix Blocked Error。如果被阻止的TLP是Non-Posted Request，则 Egress Port 将返回带有 Unsupport Request 完成状态的 Completon。TLP Prefix Blocked Error是报告的与Egress Port相关的错误（请参见Section 6.2）。

• 对于启用了多播的路由元素（请参见Section 6.14）。End-End TLP Prefix在TLP的所有多播副本中复制。在每个Egress Port 独立执行多播数据包的TLP Prefix Egress Blocking。

2.2.10.2.1 Vendor Defined End-End TLP Prefix

如Table 2-37所述，类型VendPrefixEO和VendPrefixE1 保留用作 Vendor Defined End-End TLP Prefix。为了最大程度地提高互操作性和灵活性，将以下规则应用于此类前缀：

• 除非已明确启用（使用供应商特定的机制），否则组件不得发送包含Vendor Defined End-End TLP Prefix的TLP。
• 建议组件是可配置的（使用特定于供应商的机制），以便可以使用两种Vendor Defined End-End TLP Prefix编码中的任何一种来发送所有供应商定义的前缀。这样的配置不必是对称的（例如，链路的每一端都可以使用不同的编码来发送相同的前缀）。

2.2.10.2.2 Root Ports with End-End TLP Prefix Supported

支持在Root Port之间包含End-End TLP Prefix的TLP的对等路由（peer-to-peer routing）是可选的，并且取决于实现。如果RC支持两个或多个Root Port 之间的End-End TLP Prefix的路由功能，则必须在每个相关的Root Port 中通过 Device Capabilities 2寄存器中的End-End TLP Prefix Supported 字段指示支持该功能。

不需要RC来支持在所有End-End TLP Prefix Supported 字段设置为1b的Root Port之间的 End-End TLP Prefix路由。带有需要在不支持的Root Port之间进行路由的带有End-End TLP Prefix的请求，必须作为Unsupported Request处理。需要在不支持的Root Port 之间进行路由的带有End-End TLP Prefix的Completion，必须作为Unexpected Completion处理。在两种情况下，此错误均由“发送”端口报告。

必须为任何支持通过主机软件或RC集成端点发起的带有End-End TLP Prefix的TLP转发的根端口设置End-End TLP Prefix Supported 字段。必须为所有支持将在Ingress Port 上接收到的带有End-End TLP Prefix的TLP转发到RCiEP的根端口设置End-End TLP Prefix Supported字段。

设置了End-End TLP Prefix Supported 字段的各种Root Port可以拥有不同的Max End-End TLPPrefixes值。

当在根端口之间执行对等路由时，将TLP拆分为较小TLP的RC必须在每个较小TLP中复制原始TLP的End-End TLP Prefix（请参阅Section 1.3.1）。