PCIE协议-2-事务层规范-Message Request Rules-Vendor_Defined Messages

2.2.8.6 厂商定义消息

厂商定义消息允许扩展PCI Express消息功能，可以作为PCI Express规范的一般扩展，也可以是厂商特定的扩展。本节通用地定义了与这些消息相关的规则。

厂商定义消息（见表2-25）使用图2-28中显示的头标格式。
requester ID是特定实现的。强烈建议requester ID字段包含与请求者相关联的值。
如果使用按ID路由，则byte8和9形成一个16位的destination ID字段------否则这些字节是保留的。
byte 10和11形成一个16位的厂商ID字段，由定义消息的厂商根据PCI-SIG定义。
byte12到15可供厂商定义。

数据有效载荷可以包含在任何类型的厂商定义消息中（如果没有包含数据有效载荷，则TLP类型为Msg；如果包含数据有效载荷，则TLP类型为MsgD）。
由不同厂商或PCI-SIG定义的消息通过VendorID字段中的值来区分。

特定厂商定义的消息的进一步区分超出了本文档的范围。
对特定厂商定义的消息的支持是实现特定的，并且超出了本文档的范围。
完成者（Completers）会默默丢弃它们未设计接收的厂商定义类型1消息------这不是错误条件。
完成者处理接收到的不支持的厂商定义type0消息，作为不支持的请求（Unsupported Request），并且根据第6.2节报告错误。
[PCIe-to-PCI-PCI-X-Bridge-1.0]为旨在与PCI-X设备ID消息互操作的厂商定义消息定义了额外的要求。这包括对Tag[7:0]字段和Length[9:0]字段内容的限制，以及对消息头标byte12到15的特定使用。仅打算在PCI Express环境中使用（即，不打算解决PCI Express到PCI/PCI-X桥接器背后的目标）的厂商定义消息不受额外规则的约束。

2.2.8.6.1 PCI-SIG定义的VDMs

PCI-SIG定义的VDMs是使用PCI-SIG厂商ID（0001h）的厂商定义type1消息。作为厂商定义type1消息，如果完成者没有实现它，则每个都会被默默丢弃。除了其他厂商定义type1消息的规则外，以下规则适用于PCI-SIG定义的VDMs的形成：

PCI-SIG定义的VDMs使用图2-29中显示的头标格式。
请求者ID字段必须包含与请求者相关联的值。
消息代码必须是01111111b。
厂商ID必须是0001h，这是分配给PCI-SIG的。
子类型字段用于区分特定的PCI-SIG定义的VDMs。

2.2.8.6.2 LN消息

LN协议定义了LN消息，这些是PCI-SIG定义的厂商type1消息（VDMs）。每个消息的有效载荷通常包含一个已更新或已逐出的寄存缓存行的64位地址。64位单地址格式既用于64位也用于32位地址。由于每个LN消息都是厂商定义type1消息，如果完成者（Completer）接收到一个正确形成的LN消息，而完成者不认识该消息，则必须默默丢弃它。

LN消息可以被定向到使用基于ID的路由的单个EP，或者广播到给定根端口下的所有设备。广播LN消息是否发送到RC（根复合体）中的所有根端口是硬件定义的。

除了其他PCI-SIG定义的VDMs的规则外，以下规则适用于LN消息的形成：

表2-27和图2-30定义了LN消息。
每个消息必须包含一个2DW数据有效载荷。
Fmt字段必须是011b（4DW头标，含数据）。
TLP类型必须是MsgD。
长度字段必须是2。
TC[2:0]字段必须是000b。
Attr[2]，基于ID的排序（IDO）位，不是保留的。
Attr[1]，宽松排序（RO）位，不是保留的。
Attr[0]，无监听（No Snoop）位，是保留的。
LN位是保留的（与之相对，对于LN读取、LN写入和LN完成，必须设置LN位）。
Tag字段是保留的。
如果LN消息是广播版本，则目标ID字段是保留的。
子类型字段必须是00h。
如果系统中生效的缓存行大小为128字节，缓存行地址中的bit6必须是清除的。对于接收LN消息的轻量级通知请求者（Lightweight Notification Requester LNR），如果LNR控制寄存器中的LNR CLS位被设置，为128字节缓存行配置LNR，LNR必须忽略缓存行地址中bit6的值。
Notification Reason（NR）字段如表2-26所示进行编码，指示发送LN消息的具体原因。这些编码适用于LN消息的定向和广播版本。

2.2.8.6.3 设备就绪状态（Device Readiness StatusDRS）消息

设备就绪状态（DRS）协议使用PCI-SIG定义的厂商定义消息机制（VDM，见第2.2.8.6.1节）。DRS消息是PCI-SIG定义的厂商type1消息（Vendor-Defined Type 1 Message），没有有效载荷。除了其他PCI-SIG定义的VDMs的规则外，以下规则适用于DRS消息的形成：

表2-28和图2-31展示并定义了DRS消息。
TLP类型必须是Msg（消息）。
TC[2:0]字段必须是000b。
Attr[2:0]字段是保留的。
Tag字段是保留的。
子类型字段必须是08h。
消息路由字段必须设置为100b - 本地 - 在接收器处终止。

接收器可以（但非必须）检查这些规则的违规情况（但不能检查保留位）。这些检查是独立的可选检查（见第6.2.3.4节）。如果实施这些检查的接收器确定TLP违反了这些规则，该TLP是一个畸形TLP。

如果进行了检查，这是一个与接收端口相关联的报告错误（见第6.2节）。

2.2.8.6.4 功能就绪状态消息（Function Readiness Status MessageFRS消息）

功能就绪状态（FRS）协议使用PCI-SIG定义的厂商定义消息机制（VDM，见第2.2.8.6.1节）。FRS消息是PCI-SIG定义的厂商type1消息（Vendor-Defined Type 1 Message），没有有效载荷。除了其他PCI-SIG定义的VDMs的规则外，以下规则适用于FRS消息的形成：

表2-29和图2-32展示并定义了FRS消息。
TLP类型必须是Msg（消息）。
TC[2:0]字段必须是000b。
Attr[2:0]字段是保留的。
Tag字段是保留的。
子类型字段必须是09h。
FRS Reason[3:0]字段指示为什么生成FRS消息：
- 0001b：接收到DRS消息
  - 由消息请求者ID指示的下游端口接收到一个DRS消息，并且链路控制寄存器中的DRS信号控制字段设置为DRS到FRS信号使能。
- 0010b：D3Hot到D0转换完成
  - 一个D3Hot到D0的转换已经完成，由消息请求者ID指示的功能现在配置就绪，并且根据No_Soft_Reset位的设置（见第7.5.2.2节），返回到未初始化或D0 active状态。
- 0011b：FLR完成
  - 一个功能级重置（FLR）已经完成，由消息请求者ID指示的功能现在配置就绪。
- 1000b：VF已启用（VFEnabled）
  - 消息请求者ID指示一个物理功能（PF）------与该PF关联的所有虚拟功能（VFs）现在配置就绪。
- 1001b：VF已禁用（VFDisabled）
  - 消息请求者ID指示一个PF------与该PF关联的所有VFs已被禁用，并且现在可以访问该PF中的SR-IOV数据结构。
- 其他值：
  - 所有其他值均为保留。
消息路由字段必须清除为000b ------ 路由到根复合体（Routed to Root Complex）。

如果进行了检查，这是一个与接收端口相关联的报告错误（见第6.2节）。

FRS消息的格式如下图2-32所示：

2.2.8.6.5 层次结构ID消息（Hierarchy ID Message）

层次结构ID使用PCI-SIG定义的VDM机制（见第2.2.8.6.1节）。层次结构ID消息是PCI-SIG定义的VDM（厂商type1消息）带有有效载荷（MsgD）。

除了其他PCI-SIG定义的VDMs的规则外，以下规则适用于层次结构ID消息的形成：

表2-30和图2-33展示并定义了层次结构ID消息。
TLP类型必须是MsgD。
每个消息必须包含一个4双字（4-DWORD）数据有效载荷。
长度字段必须是4。
TC[2:0]字段必须是000b。
Attr[2:0]字段是保留的。
标签字段是保留的。
子类型字段是01h。
消息路由字段必须是011b - 从根复合体广播。

接收器可以（但非必须）检查这些规则的违规情况（但不能检查保留位）。这些检查是独立的可选检查（见第6.2.3.4节）。如果实施这些检查的接收器确定TLP违反了这些规则，该TLP是一个格式错误的TLP。如果进行了检查，这是一个与接收端口相关联的报告错误（见第6.2节）。

每个层次结构ID消息的有效载荷包含系统GUID的低128位。

有关层次结构ID、GUID授权ID和系统GUID字段的详细信息，见第6.26节。

2.2.8.7 被忽略的消息（Ignored Messages）

在本文档中列出的消息之前是用于一个不再被支持的机制（热插拔信号）。强烈建议发送器不要传输这些消息，但如果实现了消息传输，它必须符合本规范1.0a版本的要求。接收器强烈建议忽略这些消息的接收，但允许按照本规范1.0a版本的要求处理这些消息。

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

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

2.2.8.8 延迟容忍度报告（Latency Tolerance ReportingLTR）消息

LTR消息可选择性地用于报告设备关于其对读写服务延迟容忍度的行为。有关LTR的详细信息，请参见第6.18节。以下规则适用于LTR消息的形成：

表2-32定义了LTR消息。
LTR消息不包含数据有效载荷（TLP类型是Msg）。
长度字段是保留的。
LTR消息必须使用默认的流量类别设计符（TCo）。实现LTR支持的接收器必须检查此规则的违规情况。如果接收器确定TLP违反了此规则，它必须将TLP作为畸形TLP处理。
- 这是一个与接收端口相关联的报告错误（见第6.2节）。

2.2.8.9 优化缓冲区冲刷/填充（Optimized Buffer Flush/Fill OBFF）消息

OBFF消息可选择性地用于向端点报告平台中央资源状态。此机制在第6.19节中有详细描述。以下规则适用于OBFF消息的形成：

表2-33定义了OBFF消息。
OBFF消息不包含数据有效载荷（TLP类型是Msg）。
长度字段是保留的。
请求者ID必须设置为发送端口的ID。
OBFF消息必须使用默认的流量类别设计符（TC0）。实现OBFF支持的接收器必须检查此规则的违规情况。如果接收器确定TLP违反了此规则，它必须将TLP作为畸形TLP处理。
- 这是一个与接收端口相关联的报告错误（见第6.2节）。

2.2.8.10 精确时间测量（Precision Time MeasurementPTM）消息

表2-34定义了PTM消息。

PTM请求和PTM响应消息必须使用TLP类型为Msg，并且不得包含数据有效载荷。长度字段是保留的。
- 图2-36展示了PTM请求和响应消息的格式。
PTM响应D（Data）消息必须使用TLP类型为MsgD，并且必须在TLP头的byte8到15中包含一个64位的PTM主时间字段，以及包含32位传播延迟字段的1DW有效载荷。
- 图2-37展示了PTM响应D消息的格式。
- 有关如何填充PTM响应D消息的详细信息，请参见第6.22.3.2节。
请求者ID必须设置为发送端口的ID。
PTM对话被定义为由PTM请求和相应的PTM响应或PTM响应D消息组成的匹配对。
PTM消息必须使用默认的流量类别设计符（TC0）。实现PTM的接收器必须检查此规则的违规情况。如果接收器确定TLP违反了此规则，它必须将TLP作为畸形TLP处理。
- 这是一个与接收端口相关联的报告错误（见第6.2节）。