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 Status DRS)消息
设备就绪状态(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 Message FRS消息)
功能就绪状态(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数据结构。
- 其他值:
- 所有其他值均为保留。
- 0001b:接收到DRS消息
- 消息路由字段必须清除为000b —— 路由到根复合体(Routed to Root Complex)。
接收器可以(但非必须)检查这些规则的违规情况(但不能检查保留位)。这些检查是独立的可选检查(见第6.2.3.4节)。如果实施这些检查的接收器确定TLP违反了这些规则,该TLP是一个畸形TLP。
- 如果进行了检查,这是一个与接收端口相关联的报告错误(见第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 Reporting LTR)消息
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 Measurement PTM)消息
表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节)。