CXL事务层详解

第三章 CXL事务层

3.1 CXL.io

CXL.io为IO设备提供非一致性的load/strore接口。事务类型、事务数据包格式、信用流量控制、虚拟通道管理、事务顺序的规则等遵循PCIe协议。CXL.io的事务层如下图中的黄色部分所示。

3.1.1 CXL.io端点（Endpoint）

CXL设备需要支持在CXL 1.1和CXL 2.0模式下运行。当链路配置为在CXL 1.1模式下运行时，CXL.io端点必须作为PCIe RCiEP;而当配置为在CXL 2.0模式下运行时，必须作为PCI Express端点。

RCiEP是Root Complex Integrated Endpoints的缩写，PCIe端点的一种。

3.1.2 CXL电源管理VDM（Vendor Defined Message）格式

CXL电源管理消息使用PCIe的VDM Type 0，带有4DW的负载数据，包括PMREQ，PMRSP和PMGO消息。

CXL电源管理VDM的格式如下：

如果接收方CXL组件接收到“有毒”的电源管理VDM，则应丢弃此类消息。由于接收方在接收到此类VDM后能够继续正常运行，因此应将此事件视为非致命性错误（non-fatal）。如果接收方的电源管理单元（PMU）不理解电源管理VDM数据负载的内容，则应无声地丢弃该消息，并且不发出无法纠正错误（uncorrectableerror）的信号。

数据负载的字段定义比较多，就不贴图了。

电源管理信用和初始化过程是本地链接。设备和主机之间通过CXL.io通道发送的消息类型主要涉及两种，分别是CREDIT_RTN和AGENT_INFO，其中PM2IP是主机发给设备的电源管理消息，而IP2PM是设备发给主机的电源管理消息。至于“信用”机制就不解释了，在前面讲CCIX的时候已经介绍过了。

所谓的上游端口（Upstream Port）指的是设备的端口；而下游端口（Downstream Port）是主机端口。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信用数。下游端口PMU还使用第一条CREDIT_RTN消息为上游端口PMU分配PM_AGENT_ID。此ID通过CREDIT_RTN消息中的TARGET_AGENT_ID字段进行通信。在启动任何IP2PM消息之前，上游端口PMU必须等待来自下游端口PMU的CREDIT_RTN消息

参考下图，第一条消息，PM2IP.CREDIT_RTN（Target_Agent_ID，Num_Credits=1) ，这个消息里面包含了2个内容，一个是Target_Agent_ID，另一个是主机给了设备1个信用值。之后，设备也给主机发送了一个消息IP2PM. CREDIT_RTN（Num_Credits=2），授权了主机2个信用值。在初始化的时候，设备必须先等待接受来自主机的CREDIT_RTN消息，而不能先向主机发送消息。

上游端口PMU必须遵循的规则：

在启动任何IP2PM消息之前，上游端口PMU必须等待接收PM2IP.CREDIT_RTN消息。

上游端口PMU必须从下游端口PMU接收到的第一条PM2IP消息中提取TARGET_AGENT_ID字段，并将其用作未来消息中的PM_AGENT_ID。

上游端口PMU必须实现足够的资源来接收和处理任何CREDIT_RTN消息，而不依赖于任何其他PM2IP或IP2PM消息或其他消息类。

上游端口PMU必须实现至少一个信用，以接收PM2IP消息。

上游端口PMU必须尽快向下游端口PMU返回信用，以防止通过CXL链路阻塞电源管理消息通信。

建议上游端口PMU占用信用额度不得超过10us。

插播一句，是不是看的晕晕的？这里简单介绍一下供应商定义的消息（VDM），PCIe协议里是这么说的“TheVendor Defined Messages allow expansion of PCI Express messaging capabilities,either as a general extension to the PCI Express Specification or avendor-specific extension”。

3.1.3 CXL错误VDM格式

CXL错误消息使用PCIe的VDM Type 0，没有负载数据，格式如下。

3.1.4 CXL所需的可选PCIe功能

3.1.5 错误传播

设备检测到的CXL.cache和CXL.mem错误通过CXL.io通信流传播到上游端口。这些错误在PCIe AER寄存器中记录为可纠正（Correctable）和不可纠正（Uncorrectable）的内部错误。

3.1.6 ATS上的存储器类型指示

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

插播一句，ATS是Address Translation Services的缩写。PCIe协议里面有一整章讲ATS。为节省CPU资源，I/O Function常采用DMA方式访问内存。一般I/O Function看到的物理地址空间与CPU一样。但有时候，I/O Function看到的地址空间不是真实的物理地址，需要RC将DMA请求进行处理，通过一次地址转换才能将访问到真实的物理地址。这种地址转换机制有利于访问权限检查。

一般PCIe设备在本地实现一个地址缓存（Address Translation Cache，ATC），类似CPU中的TLB。Function发送存储器读写请求前，先在本地的ATC中查找是否有该地址的条目。如果在ATC中查找成功，直接采用转换后地址进行访问。如果在ATC中没有找到该地址的条码，则给TA（TranslationAgent）发送该地址的地址转换请求。在ARM体系中，TA的功能由SMMU（System Memory Management Unit）承担，此外SMMU还要显式的负责同步TLB和与它相连的分布ATC中的数据一致性。关于SMMU，之前的文章介绍过。

3.1.7 可延迟写

CXL规范中定义的可延迟写入仅在CXL1.1模式下运行时适用。在CXL 2.0模式下操作时，请参阅PCIe规范以了解此功能。

审核编辑：汤梓红