CXL协议-第三章 CXL事务层

3 CXL事务层

        

3.1 CXL.IO

CXL.io为I/O设备提供了一个非一致的负载/存储接口。图3-1显示了Flex总线分层层次结构中的位置。事务类型、事务分组格式、基于信用的流量控制、虚拟通道管理和事务排序规则遵循PCIe*定义，详情请参考PCIe基础规范的“事务层规范”章节。本章重点介绍了用于CXL.io的著名的PCIe操作模式或特性。

Figure 3-1. Flex Bus Layers - CXL.io Transaction Layer Highlighted

3.1.1 CXL.io Endpoint

        CXL替代协议协商确定了操作模式。有关如何在CXL.io的帮助下枚举CXL设备的描述，请参阅第9.11节和第9.12节。

        如果CXL设备上的Function参与了CXL.cache协议或CXL.mem协议，则该Function不能生成INTx消息。非CXL Function映射DVSEC（第8.1.4节）枚举不参与CXL.cache或CXL.mem的Function。即使不推荐使用，也允许这些非CXL Function生成INTx消息。

        与MLD组件中的LD相关联的Function，包括非CXL Function，不允许生成INTx消息。

3.1.2 CXL Power Management VDM Format

        CXL电源管理消息以PCIe供应商定义的0号类型消息的形式发送，具有4-DWORD的数据负载。这其中包括PMREQ、PMRSP和PMGO消息。图3-2和图3-3提供了CXL PM VDM消息的格式。以下是这些消息的特征：

1. Fmt和Type字段被设置为指示带有数据的消息。所有邮件都使用“在接收端本地终止”的路由。消息代码被设置为供应商定义的类型0。
2. 供应商ID字段设置为1E98h.
3. 字节15包含VDM代码，并被设置为“CXL PM消息”的值（68h）。
4. 4-DWORD数据有效负载包含CXL PM逻辑操作码（例如，PMREQ、GPF）和与CXL PM消息相关的任何其他信息。表3-1描述了数据有效负载中的字段的详细信息。

        如果CXL组件接收到带有poisoned的PM VDM（EP=1），接收器应删除这样的信息。由于接收方在接收到这样的VDM后能够继续正常操作，因此应将此事件视为警告非致命错误。

        如果接收方电源管理单元（PMU）不了解PM VDM有效负载的内容，它应悄无声地删除该消息，并不得发出不可纠正的错误的信号。

Figure 3-2. CXL Power Management Messages Packet Format - Non-Flit Mode

Figure 3-3. CXL Power Management Messages Packet Format - Flit Mode

Table 3-1. CXL Power Management Messages - Data Payload Field Definitions (Sheet 1 of 2)

Table 3-1. CXL Power Management Messages - Data Payload Field Definitions (Sheet 2 of 2)

Table 3-2. PMREQ Field Definitions

Payload Bit Position	LTR Field
[31:24]	Snoop Latency[7:0]
[23:16]	Snoop Latency[15:8]
[15:8]	No-Snoop Latency[7:0]
[7:0]	No-Snoop Latency[15:8]

3.1.2.1 Credit and PM Initialization

        PM 信用和初始化过程是本地链接的。图3-4说明了PM2IP.CREDIT_RTN和PM2IP.AGENT_INFO的使用情况。消息来初始化电源管理消息传递协议，旨在促进下游端口PMU和上游端口PMU之间的通信。如第9.1.2.1节所述，CXL switch为PM消息提供了一个聚合功能。

        GPF消息不需要积分，接收方不得为响应GPF消息生成CREDIT_RTN。

Figure 3-4. Power Management Credits and Initialization

        CXL上游端口PMU必须能够接收和处理CREDIT_RTN消息，而不依赖于任何其他PM2IP消息。此外，CREDIT_RTN消息不使用信用证。CREDIT_RTN消息用于初始化和更新每边的Tx信用，以便可以适当地管理流控制。在PM初始化期间的第一个CREDIT_RTN消息中，通过NUM_CREDITS字段发送的信用表示CREDIT_RTN的启动器可以从另一端接收到的与信用相关的PM消息的数量。在随后的CREDIT_RTN消息中，NUM_CREDITS字段表示自上一条CREDIT_RTN消息以来在同一方向上释放的PM积分的数量。第一个CREDIT_RTN消息也被下游端口PMU用来为上游端口PMU分配一个PM_AGENT_ID。此ID通过CREDIT_RTN消息中的TARGET_AGENT_ID字段进行通信。上游端口PMU必须等待任何IP2PM CREDIT_RTN消息，才能启动来自下游端口PMU的CREDIT_RTN消息。

        上游端口PMU必须支持至少一个信用，其中信用意味着有足够的缓冲来接收具有128位有效负载的PM2IP消息。

        信用初始化后，上游端口PMU必须等待来自下游端口PMU的AGENT_INFO消息。此消息包含下游端口PMU的PM协议的CAPABILITY_VECTOR。上游端口PMU必须将其CAPABILITY_VECTOR发送到下游端口PMU，以响应来自下游端口PMU的AGENT_INFO要求。当出现不匹配时，下游端口PMU可以实现兼容模式，与能力较差的上游端口PMU一起工作。或者，如果下游端口PMU不知道如何使用功能较差的上游端口PMU，则可以可靠地记录不匹配并报告错误。

        预计上游端口PMU会在收到消息后立即将积分恢复到下游端口PMU的信用。下游港口PMU可以在飞行中有多个消息，如果它有多个积分。及时发布信用证可以为对延迟敏感的流提供更好的性能。

        下面的列表总结了上游端口PMU必须遵循的规则。

1. 上游端口PMU必须等待才能接收到PM2IP。在启动任何IP2PM消息之前的CREDIT_RTN消息。
2. 上游端口PMU必须从从下游端口PMU接收到的第一个PM2IP消息中提取TARGET_AGENT_ID字段，并在以后的消息中将其用作其PM_AGENT_ID。
3. 上游端口PMU必须实现足够的资源来接收和处理任何CREDIT_RTN消息，而不依赖于任何其他PM2IP或IP2PM消息或其他消息类。
4. 上游端口PMU必须实现至少一个信用证才能接收PM2IP消息。
5. 上游端口PMU必须尽快将任何积分返回到下游端口PMU，以防止通过CXL链接阻塞PM消息通信。
6. 上游端口PMU不要扣留信用超过10微秒。

3.1.3 CXL Error VDM Format

        CXL错误消息以PCIe供应商定义的0类型消息发送，没有数据负载。目前，此类包括一种单一类型的消息，即事件固件通知（EFN）。当使用EFN来报告内存错误时，它被称为内存错误固件通知（MEFN）。图3-5和图3-6提供了EFN消息的格式。

        以下是EFN消息的特征：Fmt和Type字段被设置为表示没有数据的消息。

1. 使用“路由到根复杂”的路由发送消息。它总是是由一个设备启动的。
2. 消息代码被设置为供应商定义的类型0。
3. 供应商ID字段设置为1E98h。消息头的
4. 字节15包含VDM代码，并被设置为“CXL错误消息”（00h）的值。
5. 字节8、9、12和13被设置为0。字节14的
6. 位[7：4]被设置为0h。字节14的位[3：0]用于通信固件中断向量（在图3-5和图3-6中简称为FW中断向量）。

Figure 3-5. CXL EFN Messages Packet Format - Non-Flit Mode

Figure 3-6. CXL EFN Messages Packet Format - Flit Mode

        FW中断向量字段的编码是特定于主机的，因此不是由CXL规范定义的。主机可能支持多种类型的固件环境，此字段可用于向主机指示这些环境将处理此消息。

3.1.4 Optional PCIe Features Required for CXL

        表3-3列出了CXL根据PCIe基础规范所需的可选特性。

 注：在发布本规范时，PCIe基础规范正在进行“无序I/O”ECN操作。这可能会为设备、主机和/或交换机引入新的要求。附录B中包含了CXL使用模型的基本流程和期望。

Table 3-3. Optional PCIe Features Required for CXL

3.1.5 Error Propagation

        设备检测到的CXL.cache和CXL.mem错误通过CXL.io流量流向上游传播。这些错误被记录为检测组件的PCIe AER寄存器中的可纠正和不可纠正的内部错误。

3.1.6 Memory Type Indication on ATS

        对某些内存区域的请求只能在CXL.io上发出，而不能在CXL.cache上发出。它是由主机来决定这些记忆区域是什么。例如，在x86系统上，主机可以选择只通过CXL.io限制对不可缓存（UC）类型内存的访问。主机通过对设备的ATS完成情况的指示来指示这些区域。

        所有发出ATS请求的CXL function必须将ATS能力寄存器中的页面对齐请求位设置为1。此外，来自CXL设备的ATS请求必须设置CXL Src位。

Figure 3-7. ATS 64-bit Request with CXL Indication - Non-Flit Mode

        ATS 64位请求和32位请求的ATS3位3携带CXL Src位。图3-7显示了该位在ATS64位请求（非Flit模式）中的位置。有关其他请求消息的格式，请参阅PCIe基本规范。CXL Src位的定义如下：

1. 0-表示由一个不支持CXL的函数发起的请求。在ATS上的io指示。
2. 1-指示由支持CXL的函数发起的请求。所有的CXL函数都必须设置此位。

注意：此位保留在由PCIe基本规范定义的ATS请求中。

        来自主机的ATS翻译完成会在翻译完成数据条目中携带CXL.io位。有关消息格式，请参见PCIe基本规范。当设置了请求中的CXL Src位时，ATS转换完成中的CXL.io位将有效。CXL.io位的定义如下：

1. 0-可以在所有的CXL协议上发出对该页面的请求。
2. 1-对页面的请求只能由CXL.io上的function发出。使用CXL.cache协议向页面发出请求是违反规则的。

3.1.7 Deferrable Writes

        本规范的早期版本捕获了对CXL.io协议的“可延迟写入”扩展，但该协议已被PCIe基础规范所采用。

3.1.8 PBR TLP Header (PTH)

        在PBR结构中的PBR链接上，除NOP-TLP外，所有.ioTLP都携带一个固定的1- DWORD头字段，称为PBR TLP头（PTH）。PBR链接可以是交换机间链接（ISL）或从PBR交换机到G-FAM的边缘链接。有关在.io TLP从源到目标穿越PBR结构时插入和删除该标头的详细信息，请参见第7.7.6节。

        NOP-TLPs总是传输没有之前的PTH。对于非nop-TLP，PTH总是在TLP头基之前的直接DWORD上传输。如果有与TLP相关联的本地前缀，则总是在PTH传输之前进行传输。这如图3-8所示。

        为了帮助PBR链路上的接收器消除NOP-TLP/Local前缀中PTH的歧义，PCIe flit模式TLP语法被修改如下。所有DWORDs的第一个字节的7：6位，从TLP的第一个DWORD到检测到PTH，编码如下：

1. 00b=NOP-TLP
2. 01b=Rsvd
3. 10b=本地前缀
4. 11b = PTH

        在接收方检测到PTH后，根据PCIe基本规范应用PCIe TLP语法规则，直到TLP结束，但限制NOP-TLP和本地前缀不能在TLP的这个区域传输。

3.1.8.1 Transmitter Rules Summary

1. 对于NOP-TLP和局部前缀类型1字段编码，没有PTH
2. 对于所有其他类型1字段编码，PTH预先在Header base前面

3.1.8.2 Receiver Rules Summary

1.         对于NOP-TLP，如果位5：0不是所有0，接收器把它作为一个错误包和报告错误相关错误报告规则后
2. 本地前缀，如果位5：0不是00_1101b - 00_1111b，接收器把它作为一个错误包和报告相关错误报告规则
3. 从TLP PTH检测时，接收器默默下降DWORD如果Rsvd值01b位7：6 DWORD
4. 如果收到NOP-TLP或本地前缀后立即收到PTH，接收方将其视为一个畸形的数据包，并按照相关的错误报告规则报告错误

注意：PBR交换机/设备中的头队列应该能够处理需要在源和目标PBR链路之间携带的PTH的额外DWORD。

注： PTH作为正常链路级CRC/FEC计算/PBR链路检查的一部分，以确保通过PBR链路进行可靠的PTH交付。

        在MLD链接上，在出口方向上，这个标头中的SPID信息用于生成vend MLD 0消息中在第2.4节中定义的LD-ID信息。在MLD链接上，在入口方向上，VendPrefixL0消息中的LD-ID用于确定PBR数据包中的DPID。

Table 3-4. PBR TLP Header (PTH) Format

Table 3-5. NOP-TLP Header Format

Table 3-6. Local Prefix Header Format

Figure 3-8. Valid .io TLP Formats on PBR Links

3.2 CXL.cache

3.2.1 Overview

        CXL.cache协议将设备和主机之间的交互定义为每个请求至少有一个关联的响应消息，有时还有一个数据传输的多个请求。该接口由每个方向上的三个通道组成：请求、响应和数据。这些通道以其方向命名：设备到主机的D2H和主机到设备的H2D，以及它们所携带的事务、请求、响应和数据，如图3-9所示。独立的通道允许不同类型的消息使用专用线，并实现解耦和更高的每线有效吞吐量。

        “D2H请求”会将新的请求从设备传送到主机。这些请求通常是针对内存的。每个请求将接收零、一个或两个响应，最多接收一个64字节的粗轴数据。该渠道可能会无压力。D2H响应系统会将所有响应从设备传递到主机。设备对窥探的响应表示该行留在设备缓存中的状态，并可能表示数据正在返回到主机到所提供的数据缓冲区。他们仍然可能被暂时链接为链接层学分。D2H数据携带所有数据和字节启用从设备到主机。数据传输可以来自隐式（由于窥探的结果）或显式回写（由于缓存容量排出的结果）。

        一个完整的64字节的数据的坐标轴总是被传输的。D2H数据必须取得进展，否则可能会发生死锁。D2H数据可能会暂时阻止链接层积分，但不需要任何其他D2H交易完成以释放积分。

        H2D请求会将请求从主机传送到设备。这些是为了保持一致性而窥探。数据可以返回给窥探者。请求携带任何返回数据应该写入的数据缓冲区的位置。H2D请求可能因缺乏设备资源而返回压力；但是，资源必须释放，而不需要D2H请求来取得进展。H2D响应携带排序消息和提取写入数据。每个响应都携带来自原始设备请求的请求标识符，以指示响应应该路由的位置。对于写入数据拉响应，消息携带应该写入数据的位置。H2D响应只能暂时阻止链接层信用。H2D数据为设备读取请求提供数据。在所有情况下，都传输完整的64字节的数据线数据。H2D数据传输只能暂时阻止链接层信用。

Figure 3-9. CXL.cache Channels

3.2.2 CXL.cache Channel Description

3.2.2.1 Channel Ordering

        通常，所有CXL.cache通道必须相互独立工作，以确保保持前进进度。例如，因为从设备到主机到给定地址X的请求将被主机阻止，直到它收集到这个地址X的所有窥探响应，所以链接通道将导致死锁。

        但是，有一个特定的实例，为了正确性，必须维护通道之间的排序。主机需要等待设备观察到H2D响应发送的全局观察（GO）消息，然后发送相同地址的后续窥探。为了限制跟踪GO消息所需的缓冲量，主机假定在给定周期中通过CXL.发送的GO消息不能通过稍后周期中发送的窥探传递。

        对于在单个通道上有多个消息的事务（例如，WrInv的读取和GO），设备/主机必须确保使用序列化消息（例如，如图3-13所示的WrInv的读取和GO之间的数据消息）。

3.2.2.2 Channel Crediting

        为了保持接口的模块化，不能对在通道上发送消息的能力做出任何假设，因为链接层积分可能一直不可用。因此，每个通道必须使用一个信用来发送任何消息，并从接收方收集信用回报。在操作过程中，接收方在处理消息时返回一个信用（即释放一个缓冲区）。不要求所有的信用都在任何一方，这就足够了。如果没有可用的信用，发送方必须等待接收方返回一个信用。下表描述了哪些通道必须排水以保持前进进度，哪些通道可以无限期地阻塞。

        表3-7定义了CXL.cache中的前进进度和信任机制的摘要，但这并不是完整的定义。有关协议正确性和前进进度所需的一整套排序规则，请参见第3.4节。

Table 3-7. CXL.cache Channel Crediting Summary

3.2.3 CXL.cache Wire Description

        下面是对每个CXL.缓存通道的每个字段的定义。中的每个消息将支持3种变体： 68B Flit、256B Flit和PBR Flit。它们的使用将在第6.0章中定义的每个链接的物理层中进行协商。

3.2.3.1 D2H Request

        下面是对每个CXL.缓存通道的每个字段的定义。中的每个消息将支持3种变体： 68B Flit、256B Flit和PBR Flit。它们的使用将在第6.0章中定义的每个链接的物理层中进行协商。

Table 3-8. CXL.cache - D2H Request Fields (Sheet 1 of 2)

Table 3-8. CXL.cache - D2H Request Fields (Sheet 2 of 2)

1.此计算中假设的公式是：“ns”=“请求数的延迟容忍度”*（每个请求64B）/“GB/s中的峰值带宽”。假设峰值带宽为256 GB/s（一个x16 CXL端口的原始双向带宽为64 GT/s），则其延迟容忍度为1024 ns。

Table 3-9. Non Temporal Encodings

3.2.3.2 D2H Response

Table 3-10. CXL.cache - D2H Response Fields

3.2.3.3 D2H Data

Table 3-11. CXL.cache - D2H Data Header Fields

3.2.3.3.1 Byte Enable

        在68B Flit模式下，数据字节使能的存在在flit头部中表示，但仅在一个或多个字节使能位的值为0时才会表示。在这种情况下，字节使能被作为数据块发送，如第4.2.2节所述。在256B Flit模式下，消息头部包含一个BEP (Byte-Enables Present)位，表示在消息末尾包含了BE插槽。字节使能字段宽度为64位，指示包含数据的字节哪些是有效的。

3.2.3.4 H2D Request

Table 3-12. CXL.cache – H2D Request Fields (Sheet 1 of 2)

Table 3-12. CXL.cache – H2D Request Fields (Sheet 2 of 2)

3.2.3.5 H2D Response

Table 3-13. CXL.cache - H2D Response Fields

Table 3-14. RSP_PRE Encodings

Table 3-15. Cache State Encoding for H2D Response

3.2.3.6 H2D Data

Table 3-16. CXL.cache - H2D Data Header Fields

3.2.4 CXL.cache Transaction Description

3.2.4.1 Device-attached Memory Flows for HDM-D/HDM-DB 

        当CXL Type 2设备使用主机管理的设备内存设备相干性（HDM-D/HDM-DB）向主机公开内存时，该 设备负责解决主机和设备之间的HDM一致性。CXL为此定义了两个协议选项：

1. CXL.用于HDM-D的高速缓存请求
2. CXL.mem反向无验证Snoop（BISnp），与HDM-DB一起使用

        支持256B Flit模式的端点设备必须支持BISnp机制，并且可以选择使用CXL。当连接到只有68B闪烁 模式的主机时，高速缓存机制。当使用CXL.cache时，主机检测到地址来自拥有设备的区域，该区域 触发返回Mem*Fwd的特殊流，如表3-19所示。

       

3.2.4.2 Device to Host Requests

3.2.4.2.1 Device to Host (D2H) CXL.cache Request Semantics

         对于设备到主机的请求，有四种不同的语义： CXL.cache read，CXL.cache read0，CXL.cache read0/write，和CXL.cache write。所有设备到主机CXL.cache事务都属于这四个语义中的一个，尽管给定语 义中每个请求类型的允许响应和限制是不同的。

3.2.4.2.2 CXL.cache Read

        CXL.cache Reads必须具有D2H请求信用，并在D2H CXL上发送请求消息。CXL.缓存读取请求需要零或一个响应（GO）消息和总共一个64字节的数据数据轴的数据消息。如果存在

，则该响应和数据消息都指向在初始D2H请求数据包的CQID字段中提供的设备跟踪器条目。在收到来 自主机的所有消息之前，设备条目必须保持活动状态。为了确保前进的进度，设备必须有一个保留 的数据缓冲区，能够在请求发送后立即接受64字节的数据。但是，由于先前的数据返回不耗尽，设备可能暂时无法接受来自主机的数据。一旦从主机同时接收到响应消息和数据消息，就可以认为事 务已完成，并从设备释放了入口。

        下图显示了完成一个CXL所需的元素。高速缓存读取。请注意，可以在数据消息之前、之后或之间接收。

Figure 3-10. CXL.cache Read Behavior

3.2.4.2.3 CXL.cache Read0

         CXL.cache read0必须具有D2H请求信用证，并在D2H CXL.cache 请求通道上发送消息。CXL.cache read0请求接收一个响应消息，但没有数据消息。响应消息指向初始D2H请求消息的CQID值中指示的设备条目。一旦收到这些请求的GO消息，可以认为它们是完成的，并从设备释放。主机不能为这些事务发送数据消息。大多数特殊循环（例如，CLFlush）和其他杂项请求都属于这一类。详见表3-17。下图显示了完成CXL.cache read0事务所需的元素。

        下图显示了完成CXL.cache read0事务所需的元素。

Figure 3-11. CXL.cache Read0 Behavior

3.2.4.2.4 CXL.cache Write

         在CXL.cache写入在D2H CXL.缓存请求通道上发送请求消息之前，必须具有D2H请求信用。一旦主机收到了请求消息，它就需要发送一个GO消息和一个写拉消息。清除数据不需要“写取”消息。GO和小写拉可以是某些请求的组合消息。GO消息不能在写拉之前到达设备，但它可以在合并的消息中同时到达。如果事务需要发布语义，那么可以使用组合的GO-I/WritePull消息。如果事务需要非发布语义，那么在全局观察非发布写入时，首先发布WritePull，然后是GO-I。

        在收到GO-I消息后，设备将从内存顺序和缓存一致性的角度考虑存储，放弃高速线的所有权（如果CXL.cache消息是驱逐）。

        写拉消息触发设备向主机发送数据消息，总共有64字节的数据，尽管可以设置任何数量的字节启用。

        一旦设备收到GO-I消息并发送了所需的数据消息，设备就会认为CXL.cache写事务已经完成。此时，可以从设备中释放该条目。

        该主机认为，一旦它收到了所有64个字节的数据，并发送了GO-I响应消息，就可以完成一次写入操作。所有设备的写和驱逐都属于CXL.cache写语义。

        有关有关多个活动写入事务的限制的更多信息，请参阅第3.2.5.8节。

Figure 3-12. CXL.cache Device to Host Write Behavior

Figure 3-13. CXL.cache WrInv Transaction

Figure 3-14. WOWrInv/F with FastGO/ExtCmp

3.2.4.2.5 CXL.cache Read0-Write Semantics

Figure 3-15. CXL.cache Read0-Write Semantics

Table 3-17. CXL.cache – Device to Host Requests (Sheet 1 of 2)

Table 3-17. CXL.cache – Device to Host Requests (Sheet 2 of 2)

3.2.4.2.6 RdCurr

3.2.5 Cacheability Details and Request Restrictions

3.2.5.1 GO-M Responses

3.2.5.2 Device/Host Snoop-GO-Data Assumptions

3.2.5.3 Device/Host Snoop/WritePull Assumptions

3.2.5.4 Snoop Responses and Data Transfer on CXL.cache Evicts

3.2.5.5 Multiple Snoops to the Same Address

3.2.5.6 Multiple Reads to the Same Cacheline

3.2.5.7 Multiple Evicts to the Same Cacheline

3.2.5.8 Multiple Write Requests to the Same Cacheline

3.2.5.9 Multiple Read and Write Requests to the Same Cacheline

3.2.5.10 Normal Global Observation (GO)

3.2.5.11 Relaxed Global Observation (FastGO)

3.2.5.12 Evict to Device-attached Memory

3.2.5.13 Memory Type on CXL.cache

3.2.5.14 General Assumptions

3.2.5.15 Buried Cache State Rules

3.3 CXL.mem

3.3.1 Introduction

3.3.2 CXL.mem Channel Description

3.3.3 Back-Invalidation Snoop

3.3.4 QoS Telemetry for Memory

3.3.5 M2S Request (Req)

3.3.6 M2S Request with Data (RwD)

3.3.7 M2S Back-Invalidate Response (BIRsp)

3.3.8 S2M Back-Invalidate Snoop (BISnp)

3.3.9 S2M No Data Response (NDR)

3.3.10 S2M Data Response (DRS)

3.3.11 Forward Progress and Ordering Rules

3.4 Transaction Ordering Summary

3.5 Transaction Flows to Device-attached Memory

3.5.1 Flows for Back-Invalidation Snoops on CXL.mem

3.5.2 Flows for Type 1 Devices and Type 2 Devices

3.5.3 Type 2 Memory Flows and Type 3 Memory Flows

3.6 Flows to HDM-M in a Type 3 Device