CXL，最强科普（上）

  摘要  

Compute Express Link（CXL）是处理器与加速器、内存缓冲器、智能网络接口、持久内存和固态硬盘等设备之间的开放式行业标准互连。CXL 提供一致性和内存语义，其带宽可与 PCIe 带宽相匹配，同时延迟大大低于 PCIe。所有主要 CPU 供应商、设备供应商和数据中心运营商都已将 CXL 作为通用标准。这样就形成了一个可互操作的生态系统，支持包括高效加速器、服务器内存带宽和容量扩展、多服务器资源池和共享以及高效点对点通信在内的关键计算用例。本调查介绍了CXL，包括 CXL 1.0、CXL 2.0 和 CXL 3.0 标准。我们将进一步调查 CXL 的实现情况，讨论 CXL 对数据中心环境的影响以及未来的发展方向。

  引言  

Compute Express Link（CXL）是一个开放的行业标准，定义了 CPU 和设备之间的一系列互连协议。虽然有 CXL 规范和新闻机构的简短摘要，但本教程旨在提供技术细节，同时让广大系统受众易于理解。CXL 协议横跨整个计算堆栈，涉及计算机科学的多个分支。为了处理这种广泛性，我们将重点放在基础工程方面，而较少关注安全特性、安全影响和更高级别的软件功能。

作为一种通用设备互连，CXL 采用了广泛的设备定义，包括图形处理器 (GPU)、通用图形处理器 (GP-GPU)、现场可编程门阵列 (FPGA)，以及各种专用加速器和存储设备。传统上，这些设备使用外围组件互连-Express®（PCI-Express® 或 PCIe®）串行接口。CXL 还针对传统上通过双倍数据速率（DDR）并行接口连接到 CPU 的存储器。

虽然 PCIe 和 DDR 对于各种设备来说都是很好的接口，但它们也有一些固有的局限性。这些限制导致了以下挑战，促使我们开发和部署 CXL：

挑战 1：连贯访问系统和设备内存。系统内存通常通过 DDR 连接，并可由 CPU 高速缓存分级缓存。相比之下，PCIe 设备对系统内存的访问是通过非一致性读/写实现的，如图 1 所示。PCIe 设备无法缓存系统内存以利用时间或空间位置性或执行原子操作序列。从设备到系统内存的每次读/写都要经过主机的根复用器 (RC)，从而使 PCIe 与 CPU 的缓存语义保持一致。同样，连接到 PCIe 设备的内存从主机进行非一致性访问，每次访问都由 PCIe 设备处理。因此，设备内存无法映射到可缓存的系统地址空间。

图 1. CXL 支持一致性和内存语义，建立在 PCIe 物理子系统之上。

非一致性访问对于流式 I/O 操作（如网络访问或存储访问）非常有效。对于加速器而言，整个数据结构在移回主存储器之前，会从系统内存移至加速器以实现特定功能，并部署软件机制以防止 CPU 和加速器之间的同时访问。这对人工智能 (AI)、机器学习 (ML) 和智能网络接口卡 (NIC) 等新的使用模式构成了障碍，在这些使用模式中，设备需要使用设备本地缓存与 CPU 同时访问相同数据结构的部分内容，而无需来回移动整个数据结构。这一挑战也出现在不断发展的内存处理（PIM）领域，该领域试图将计算迁移到数据附近。目前，PIM 设备还没有标准化的方法来连贯访问 CPU 缓存层中的数据。这导致了繁琐的编程模型，阻碍了 PIM 的广泛应用。

挑战 2：内存可扩展性。对内存容量和带宽的需求与计算量的指数增长成正比。遗憾的是，DDR 内存无法满足这一需求。这限制了每个 CPU 的内存带宽。造成这种扩展不匹配的一个关键原因是并行 DDR 接口的引脚效率低下。通过增加DDR通道进行扩展会大大增加平台成本，并带来信号完整性挑战。原则上，PCIe 引脚将是一个很好的替代方案，因为其单位引脚内存带宽更优越，即使会增加串行化/反串行化的延迟（如后面所讨论的）。例如，32GT/s 的 x16 Gen5 PCIe 端口可通过 64 个信号引脚提供 256 GB/s。DDR5-6400 的速度为 50 GB/秒，信号引脚为 200 个。PCIe 还支持使用重定时器1 实现更长的传输距离，这样可以将内存移到离 CPU 更远的地方，每个 DIMM 的功耗可超过 15 W，从而实现更出色的性能。遗憾的是，PCIe 不支持一致性，设备连接的内存无法映射到一致性内存空间。因此，PCIe 无法取代 DDR。

另一个扩展挑战是 DRAM 存储器的每比特成本最近一直保持不变。虽然有多种介质类型，包括托管 DRAM 、ReRam 、3DXP/Optane ，但 DDR 标准依赖于特定于 DRAM 的命令进行访问和维护，这阻碍了新介质类型的采用。

挑战 3：绞合导致内存和计算效率低下。当今的数据中心由于资源搁浅而效率低下。当内存等资源仍处于闲置状态，而计算等资源已被充分利用时，就会出现资源搁浅。根本原因是资源耦合过紧，计算、内存和 I/O 设备只属于一台服务器。因此，每台服务器都需要超量配置内存和加速器，以处理峰值容量需求的工作负载。例如，一台服务器上的应用程序需要比现有内存（或加速器）更多的内存（或加速器），但这台服务器无法从同一机架上另一台未充分利用的服务器借用内存（或加速器），因此必须承受页面缺失带来的性能后果。然而，在所有内核都被工作负载使用的服务器上，经常会出现内存闲置的情况。搁浅对功耗、成本和可持续性都有不利影响，也是阿里巴巴、AWS、谷歌、Meta和微软资源利用率低的原因。

挑战 4：分布式系统中的细粒度数据共享。分布式系统经常依赖于细粒度同步。底层更新通常较小，对延迟敏感，因为更新时会出现工作块。这方面的例子包括网络搜索、社交网络内容组合和广告选择等网络规模应用中的分区/聚合设计模式。在这些系统中，查询更新通常小于 2 kB（如搜索结果）。其他例子包括依赖 kB 级页面的分布式数据库和更新更小的分布式共识。以如此精细的粒度共享数据意味着，典型数据中心网络中的通信延迟会影响更新的等待时间，并减慢这些重要用例的运行速度。例如，以 50 GB/秒（400 Gbit/秒）的速度传输 4 kB 的数据只需不到 2 秒，但在当前网络中，通信延迟超过 10 秒。相干共享内存的实现有助于将通信延迟缩短到亚微秒级，稍后我们将看到这一点。

CXL 的作用。CXL的开发就是为了应对上述四项挑战和其他挑战。自 2019 年首次发布以来，CXL 已经发展了三代（见第 2 节）。每一代都规定了互连和多种协议（见第 3 节），同时保持完全向后兼容。表 1 概述了当前 CXL 的三代版本和主要用例示例。如图 1 所示，CXL 1.0 在 PCIe 物理层之上复用了一致性和内存语义。CXL 引入了定制链路层和事务层，以实现与远程插槽内存访问相当的低延迟。通过使 CXL 设备能够缓存系统内存，从而解决了挑战 1（一致性）和挑战 2（内存扩展）。这也使一致性接口标准化，促进了 PIM 系统和编程模型的广泛采用。CPU 还可以缓存设备内存，这也解决了异构计算的挑战 4（细粒度分布式数据共享）。此外，连接到 CXL 设备的内存可映射到系统可缓存内存空间。这有利于异构处理，并有助于应对内存带宽和容量扩展挑战（挑战 2）。CXL 1.0 还继续支持 PCIe 的非一致性生产者-消费者语义。

表 1. CXL 规范世代、速度和用例概览

CXL 2.0 还通过在多台主机间实现资源池来解决挑战 3（资源搁浅）。我们使用主机来指单个操作系统或管理程序控制下的单插槽或多插槽系统。资源池通过将资源（如内存）重新分配给不同的主机，而无需重新启动这些主机，从而克服了资源搁浅和碎片化问题。CXL 协议通过引入 CXL 交换机来构建一个由主机和内存设备组成的小型网络，从而实现资源池。

CXL 3.0 通过多级 CXL 交换在更大范围内解决了挑战 3。这样就能在机架甚至 pod 层构建动态可组合系统。此外，CXL 3.0 通过实现跨主机边界的细粒度内存共享，解决了挑战 4（分布式数据共享）。

CXL 需要 CPU 和设备支持。几乎所有芯片供应商都在商业产品中广泛采用 CXL，这证明该技术因其解决实际问题的能力而受到广泛欢迎。这使得 CXL 在解决关键行业挑战方面走上了一条可行之路，并得到了广泛应用。CXL 3.0 也已经达到了一定的成熟度，有助于对其基本设计选择进行审查。本教程第 2 节介绍了背景。第 3、4 和 5 节分别详细介绍了 CXL 1.0、CXL 2.0 和 CXL 3.0 的增量版本。第 6 节讨论 CXL 的实现和性能。第 7 节讨论了更广泛的影响和未来发展方向。

   2 用于未来光刻的EUV-FEL光源   

高速缓存一致性互连历来是 "对称 "的，因为它们侧重于多插槽系统或多 GPU 系统。每个节点（CPU 或 GPU）都将实施相同的一致性算法，并跟踪所需的状态。常见的例子有英特尔的快速路径互连（QPI）和超级路径互连（UPI）、AMD 的 Infinity Fabric、IBM 的 Bluelink 和 Nvidia 的 NVLink。多年来，对称互联的多种扩展试图解决第 1 节中的一些难题，如 CCIX 和 OpenCAPI。一些公司还授权使用 QPI 等协议。然而，行业经验表明，对称高速缓存一致性的复杂性和性能要求给部署带来了巨大挑战，因为协调一致性的机制在不同的架构和设计选择中存在很大差异，而且随着时间的推移而变化。此外，并非所有用例都需要一致性支持，例如挑战 2（内存扩展）和挑战 3（搁浅）。广泛采用还要求有一个即插即用的生态系统，能够与前几代产品和不同的系统架构兼容。事实证明，向后兼容性是二十多年来 PCIe 成功成为无处不在的 I/O 互连的主要原因之一。它为设备和平台制造商独立进行技术过渡提供了便利。例如，平台可能会迁移到 PCIe 第 5 代，而固态硬盘供应商可能会决定继续使用第 4 代，并在以后根据固态硬盘的技术发展进行迁移。这还有助于保护客户的投资，因为客户可能会在新平台中重复使用一些老一代设备，例如，为了减少碳排放。

在英特尔，在 PCIe 上添加简化一致性机制的想法可以追溯到 2005 年，其动机是加速器需要缓存系统内存。这导致交易处理提示使用 CPU 的高速缓存层次结构来加快设备访问速度，并在 PCIe 3.0 中添加原子语义，同时保持 PCIe 的非一致性。英特尔最初还打算在 PCIe 3.0 的基础上添加内存语义，以便通过共享内存控制器 (SMC) 实现池化。然而，PCIe 3.0 的带宽（8.0 GT/s）严重限制了使用一个 SMC 进行资源池的服务器数量。多 SMC 拓扑结构会因多次跳转而导致更高的延迟。另一个挑战是布线。2019 年，32.0 GT/s 的 PCIe 5.0（以及 64.0 GT/s 的 PCIe 6.0 的进展）和强大的电缆支持重振了英特尔的努力。英特尔由此推出了英特尔加速器链接（IAL）：一种在 PCIe 5.0 上同时支持缓存和内存的专有协议。利用二十多年来开发 PCI-Express 的经验，英特尔捐赠了 IAL 1.0 规范，并于 2019 年 3 月与阿里巴巴、思科、戴尔、谷歌、华为、Meta、微软和 HPE 共同发起了 CXL 联盟。IAL 1.0 规范更名为 CXL 1.0 规范。

CXL 在一致性、向后兼容性和开放性方面采用了非对称方法，以实现多样化和开放的生态系统，促进广泛部署。CXL 一致性与特定于主机的一致性协议细节脱钩。主机处理器还负责协调缓存一致性，以简化设备一致性的实施。设备的高速缓存代理通过一个小命令集执行简单的 MESI（修改、独占、共享、无效）一致性协议。CXL 提供多种复杂程度不同的协议，支持多种用例，设备只能实施协议的一个子集（第 3 节）。

CXL 利用 PCIe 物理层，设备插入 PCIe 插槽。CXL 的向后兼容演进（如 PCIe）及其与 PCIe 的互操作性，确保了公司对 CXL 的投资可以保证与上一代 CXL 设备以及任何 PCIe 设备的互操作性。在 PCIe 基础架构上进行构建可实现 IP 构建模块、通道和软件基础架构的重复使用，从而降低了进入门槛。从 SoC 的角度来看，多协议功能 PCIe 物理层（如图 2 所示）有助于减少硅面积、引脚数和功耗。

图 2. 利用 CXL 在 PCIe 物理层上动态复用三种协议 [8]。

CXL 于 2019 年推出时，行业内还存在 OpenCAPI、GenZ 和 CCIX 等相互竞争的互连标准。从那时起，CXL 成员已增加到约 250 家公司，所有 CPU、GPU、FPGA、网络、IP 提供商都在联盟内积极贡献力量。在英特尔于 2019 年 3 月捐赠 CXL 1.0 之后，该联盟于 2019 年 9 月发布了 CXL 1.1，增加了合规性测试机制。之后，联盟分别于 2020 年 11 月和 2022 年 8 月发布了 CXL 2.0 和 CXL 3.0，其中包括更多的使用模式，同时保持了完全的向后兼容性。随着时间的推移，行业已围绕 CXL 形成合力。例如，竞争标准 GenZ 和 OpenCAPI 向 CXL 捐赠了知识产权和资金，以支持共同标准。

   3 CXL 1.1 协议   

CXL 的第一代协议为直接连接到主机的设备引入了一致性和内存语义。这使得 CPU 和加速器能对共享数据结构进行细粒度异构处理（第 1 节中的挑战 1），并能以经济高效的方式扩展内存带宽和容量（第 1 节中的挑战 2）。

CXL 是一种非对称协议，与 PCIe 类似。主机处理器包含根复合体（RC），每个 CXL 链路一个，每个根复合体连接到作为 "端点 "的设备。主机处理器协调高速缓存一致性，如下所述。软件通过在主机处理器中执行的指令配置系统，主机处理器生成配置事务以访问每个设备。CXL 本机支持 x16、x8 和 x4 链路宽度，在降级模式下支持 x2 和 x1 宽度。降级模式是指 PCIe 链路自动进入更窄的宽度和/或更低的频率，以克服特定通道上高于预期的错误率。CXL 本机支持 32.0 GT/s 和 64.0 GT/s 的数据速率，降级模式下支持 16.0 GT/s 和 8.0 GT/s 的数据速率。

图 2 说明了 CXL 如何与 PCIe 实现完全互操作，因为它使用的是 PCIe 协议栈。CXL 设备以 2.5 GT/s 的 PCIe 第 1 代数据速率启动链路训练，如果其链路合作伙伴支持 CXL，则使用 PCIe 5.0 和 PCIe 6.0 规范中定义的备用协议协商机制协商 CXL 作为运行协议。

3.1CXL 协议和设备类型

CXL 使用三种协议实现，即 CXL.io、CXL.cache 和 CXL.memory（又名 CXL.mem），这些协议在 PCIe 物理层上动态多路复用。图 2 展示了 CXL 的多协议支持。CXL.io 协议基于 PCIe。它用于设备发现、状态报告、虚拟到物理地址转换和直接内存访问（DMA）。CXL.io 使用 PCIe 的非相干负载存储语义。现有的 PCIe 软件基础架构将通过必要的增强重新使用，以利用 CXL.cache 和 CXL.mem 等新功能。CXL.cache 用于设备缓存系统内存。CXL.mem 使 CPU 和其他 CXL 设备能将设备内存作为可缓存内存访问。CXL.mem 使连接到设备的内存成为可缓存内存（称为主机管理设备内存 (HDM)），类似于主机内存，从而实现主机在 HDM 和主机内存之间的统一视图（图 2）。如图 3 所示，CXL.io 对所有设备都是强制性的，而 CXL.cache 和 CXL.mem 则是可选的，并根据具体用途而定。

图 3. 三大类 CXL 终端设备[8]。

图 3 显示了 CXL 1.0/1.1 规范中定义的三种设备类型，它们捕捉到了不同的使用模式。类型 1 设备是智能网卡等加速器，使用一致性语义和 PCIe 式 DMA 传输。因此，它们只实施 CXL.io 和 CXL.cache 协议。类型 2 设备是 GP GPU 和 FPGA 等加速器，其本地内存可部分映射到可缓存系统内存。这些设备也缓存系统内存以进行处理。因此，它们执行 CXL.io、CXL.cache 和 CXL.mem 协议。第 3 类设备用于内存带宽和容量扩展，可用于连接不同类型的内存，包括支持连接到设备的多个内存层。因此，3 类设备将仅实施 CXL.io 和 CXL.mem 协议。CXL 第 3 类设备为服务器 CPU 增加更多 DDR 通道提供了一种成本、功耗和引脚效率高的替代方案，同时因其更长的线程长度而为系统拓扑结构提供了灵活性，从而缓解了电力传输和冷却方面的限制。CXL 采用分层协议方法。物理层负责物理信息交换、接口初始化和维护。数据链路层（或链路层）负责可靠的数据传输服务，并在设备之间建立逻辑连接。事务层负责处理与每个协议相关的事务以及任何架构排序语义、流量控制和信用。这些层中的每一层都有一组寄存器，软件可访问这些寄存器来配置、控制和获取链路状态。读者可参阅相关规范了解详情。

3.2CXL 68 字节 Flit

CXL 在 PCIe 物理层复用了三个协议。每个协议的传输单位都是一个 Flit（流量控制单元）。CXL 1.0、1.1 和 2.0 规范定义了一个 68 字节的 Flit。CXL 3.0 规范引入了额外的 256 字节 Flit，第 5 节将对此进行讨论。每个 68 字节的 Flit 包括一个 2 字节的协议标识、一个 64 字节的有效载荷和一个保护有效载荷的 2 字节 CRC（循环冗余校验）（图 4(a)）。协议标识符可划分不同类型的数据包，并具有内置冗余功能，可检测和纠正这 2 个字节内的多个位翻转。CRC 可保证在 64 字节有效载荷（加上 2 字节的 CRC）中检测到多达 4 个随机比特翻转，从而实现极低（<< 10-3）的故障时间（FIT，即链路中十亿小时内的故障次数），规范规定的误码率（BER）小于 10-12。图 4(b) 显示了 CXL.cache、CXL.mem 和 Arb/Mux 链路管理包 (ALMP) 使用的 16 字节插槽机制，其中 4 个 16 字节插槽构成了 Flit 的 64 字节有效载荷。Arb/Mux 向其链路伙伴的 Arb/Mux 设备发送 ALMP 数据包，以根据需要协调链路管理功能，如跨多个堆栈的电源管理。图 4(c) 显示了 CXL.cache 和 CXL.mem 协议使用的全数据 Flit 的布局，简称为 CXL.cache+mem，因为两者之间的区分发生在链路层，因为它们都是基于 Flit 的本地协议。CXL.io 使用 PCIe 事务/数据链路层数据包（TLP/ DLLP），这些数据包在 Flit 的有效载荷部分发送。由于 TLP 和 DLLP 有自己的 CRC（分别为 32 位和 16 位），CXL.io 数据包的接收器会忽略 16 位 Flit CRC。

图 4. CXL 68 字节 Flit 布局 [2, 8]。

CXL.cache和CXL.mem的访问延迟很低，类似于本地CPU到CPU的对称一致性链路。因此，CXL 设备的内存访问延迟类似于远程插座中 DDR 总线的内存访问延迟。虽然这比本地插槽中 DDR 总线的内存访问延迟要高，但在双插槽对称多处理系统中，由于 NUMA（非统一内存访问）的优化和更高的带宽，非空闲系统中的延迟较低，这种延迟是可以接受的。CXL.cache和CXL.mem的链路层和事务层路径具有较低的延迟，因为它们本身是基于Flit的，而且Flit的64字节有效载荷选择与这些协议的高速缓存行大小的传输相同。在物理层（PHY）级（而不是堆栈的更高级别）进行多路复用有助于为 CXL.cache 和 CXL.mem 流量提供低延迟路径。这消除了 PCIe/ CXL.io 路径链路层和事务层的较高延迟，因为它们支持可变数据包大小、排序规则、访问权限检查等，符合 CXL 规范的基本指导原则。物理层可区分 CXL.io、CXL.cache-mem、ALMP 和 NULL Flits（不发送任何内容）。在发送有序集之前，这四类 Flits 中的每一类都有两种情况来指示当前 Flit 是否是数据流的终点（EDS）。这些有序集由物理层注入，用于周期性时钟补偿或任何链路恢复事件等功能。这八种编码使用 8 位，保证汉明距离为 4，重复两次，以便进行校正和检测。每个有序集长一个区块（130 b），用于链路训练和时钟补偿。每个车道独立发送其有序集。

在以 32 GT/s 或更低的速度运行时，CXL 使用 PCIe 的 128 b/130 b 编码方案，在该方案中，每条线路上的每 128 位数据都预置 2 位同步头，以区分数据块和有序集块。如图 4（d）中 x16 链路的两个数据块所示，每个巷道上的 128 位数据有效载荷用于传输 Flits。一个 Flit 可以跨越多个数据块，一个数据块可以包含多个 Flits。由于 CXL.io 数据包（TLP 和 DLLP）本身不是基于 Flit 的，因此一个 TLP 或 DLLP 可以跨越多个 Flit，而一个 Flit 可能包含两个数据包。对这些开销进行描述，就能得到第 6.3 节讨论的有效载荷吞吐量。为了优化延迟，在协商 CXL 协议时，如果链路的所有组件（包括 Retimers（如有））在初始 PCIe 链路培训过程中宣布支持该优化，则 CXL 可移除 2 位同步头。

3.3CXL.io 协议

CXL.io 协议基于 PCIe，用于设备发现、配置、初始化、I/O 虚拟化和使用非相干负载存储语义的 DMA 等功能。与 PCIe 一样，CXL.io 也是一种基于信用的分批交易协议。拆分事务是指与 CXL.io 请求事务相关的任何完成都会在稍后时间独立异步到达。这与早期基于 PCI 总线的架构不同，在早期的架构中，事务会锁定总线，直到其完成。之所以能做到这一点，是因为每个事务都是作为独立的事务层数据包（TLP）发送的，其消耗的 "点数 "与其在接收器上消耗的缓冲空间一致。有三种流量控制类别（FC）：已发布（(P)，用于内存写入和信息）、非发布（(NP)，那些需要完成的，如内存读取和配置/I/O 读/写）和完成（C）。CXL.io 在这些 FC 上遵循 PCIe 排序规则，如图 5 所示（CXL 3.0 引入了这些排序规则的例外情况，详见第 5 节）。这些规则可确保向前推进，同时执行生产者-消费者订购模式。CXL.io 规定了两个虚拟通道，以确保服务质量（QoS）。具有不同要求和延迟特性的流量被放置在不同的虚拟通道（VC）中，以尽量减少系统中队列顶部阻塞的影响。例如，带宽大流量与对延迟敏感的等时流量可以放在不同的虚拟通道中，并且可以设置不同的仲裁策略。同样，我们可以将 DRAM 访问和持久内存访问放在两个不同的虚拟通道中，因为它们的延迟和带宽特性截然不同，以确保其中一个通道的流量不会影响另一个通道。

图 5. CXL 1.1 的 PCI-Express/ CXL.io 排序表，其中 "是 "表示事务（第 2 次传输）可以超越之前的事务（第 1 次传输），以确保向前推进。为确保生产者-消费者排序，"否 "表示不允许超越。为优化性能，"Y/N "适用于排序规则放宽的情况。

图 6(a) 描述了作为硬件和软件之间契约的生产者-消费者排序模型。这种模式在整个系统中强制执行，即使是跨越不同层次的事务，以及位于不同内存位置并可能具有不同属性（如可缓存与不可缓存）的地址位置也不例外。设备可以是 CPU、CXL/PCIe 设备或交换机中的任何实体。基本原理是，生产者产生（内存写入）数据，随后写入标记；数据和标记可以位于系统中的多个内存位置。如果消费者看到标记，就可以读取数据，并确保获得生产者写入的最新数据。标志可以是系统内存中的环形缓冲区、设备中的内存映射 I/O 位置或发送到处理器的中断。图 5 中描述的排序规则确保了生产者-消费者排序模式。排序规则的另一个作用是设备同步使用，如图 6(b) 所示。在这里，两个设备可能正在执行两个任务，并将 A 和 B 作为它们完成任务的指示器。如果读取获得的是旧数据，那么该设备中的进程可以暂停，由稍后完成执行的设备重新安排。如果（a，b）是可能的，那么两个设备中的两个进程都将永远暂停，这是不希望看到的结果。

图 6. CXL.io 和 PCIe 中的生产者-消费者订购模型。

虽然 CXL.io/PCIe 排序模型可用于某些类型的同步，但图 6(c) 所示的同步用法无法通过流水线访问来执行，因为写入可以绕过之前的读取。这种限制导致具有分区全局地址空间（PGAS）的智能网卡在排序重要时，在读取后序列化写入。CXL.cache 克服了这一限制： 设备可以不按顺序预取所有数据，并在符合程序顺序的本地高速缓存中以低延迟完成事务。

CXL.cache+mem 大部分是无序的，但在每个高速缓存行上有一些排序限制，这将在后面讨论。在支持源-目的对之间多路径的拓扑结构中，这些限制可以通过路由机制来解决，该机制可确保任何给定高速缓存行的相关事务始终遵循相同的路径。但是，传统 PCIe（和 CXL.io）的排序要求是在整个内存空间内进行的。因此，传统 PCIe（以及 CXL）必须遵循树状拓扑结构。在 CXL 3 中，我们放宽了 CXL.io 的排序要求，可以支持任何结构拓扑，详见第 5 节。

CXL.io 使用标准 PCIe DLLPs 交换信息，如积分、可靠的 TLP 传输、电源管理等。CXL.io 使用 PCIe 的配置空间，并为 CXL 的使用对其进行了增强。这有助于使用现有的设备发现机制。我们预计，PCIe 设备驱动程序将进行必要的增强，以利用 CXL.cache 和 CXL.mem 等新功能，而系统软件将对与新功能相关的新寄存器集进行编程。这建立在现有基础设施的基础上，使生态系统更容易采用 CXL。

3.4CXL.cache 协议

CXL.cache 协议使设备能够使用 MESI 一致性协议[47]缓存主机内存，缓存行大小为 64 字节。为了保持协议在设备上的简单性，主机管理所有对等缓存的一致性跟踪，而设备从不与任何对等缓存直接交互。该协议建立在每个方向的 3 个通道上。通道的方向是主机到设备（H2D）和设备到主机（D2H）。每个方向都有一个请求、响应和数据通道。通道在每个方向上都是独立流动的，但有一个例外：主机在 H2D 请求通道中发出的窥探（Snoop）信息必须在 H2D 响应中针对相同的高速缓存行地址推送之前的全局观察（GO）信息。GO 信息向设备指出一致性状态（MESI）和一致性承诺点。

CXL.cache 仅使用主机物理地址。缓存设备与中央处理器一样，在执行代码时使用虚拟地址。同样，高性能设备也应使用虚拟地址，以避免软件层提供转换。预计设备将实施与 CPU 的 TLB 类似的设备转换旁路缓冲器（DTLB），以缓存页表条目。它使用 PCIe（和 CXL.io）的地址转换服务（ATS）来获取虚拟到物理的转换以及访问控制，以确保多个虚拟机/容器之间的适当隔离。此外，CXL 还对 ATS 进行了扩展，以传达对地址的访问是允许使用 CXL.cache 还是仅限于 CXL.io。由于 DTLB 是非相干的，ATS 希望主机处理器跟踪整个平台上 DTLB 中的待处理条目，并对软件已失效的 DTLB 条目（或条目）启动失效。主机处理器使用其 ATS 硬件机制完成与 DTLB 的无效握手，然后再向正在使页表条目无效的软件指示完成。

D2H 请求通道包括 15 条命令，分为四类： 读取、读取 0、读取 0-写入、写入。如图 7 所示，"读 "类别允许设备请求高速缓存行的一致性状态和数据。响应将是 H2D 响应通道中的一致性状态（如果需要一致性）和 H2D 数据。读 0 "类请求只针对一致性状态，数据为 "0"（表示不需要数据）。它可用于升级高速缓存中的现有数据（S 到 E），或在预计写入整个高速缓存行时引入 E 状态。H2D 响应通道表示主机提供的一致性状态。读0-写 "类别允许设备直接向主机写入数据，在发出之前不需要任何一致性状态。当主机准备好接受 D2H 数据时，H2D 响应将显示 "WritePull"，主机将在显示系统全球观测 (GO) 数据之前解决一致性问题。写 "类别用于设备从设备缓存中删除数据。这些请求可以是脏数据（M 状态），也可以是清洁数据（E 或 S 状态）。在设备需要提供数据的情况下，主机将指示 "WritePull"，并指示 GO。

图 7. CXL 1.1 高速缓存协议流程。

H2D 请求通道用于主机改变设备的一致性状态，即 "窥探"（缩写为 Snp）。设备必须根据窥探类型的要求更新其缓存，如果缓存中存在脏数据（M-state），还必须将该数据返回给主机。图 7 举例说明，主机发送 SnpInv X，要求设备使地址 X 的高速缓存失效。设备将地址 X 的高速缓存状态从 E 改为 I，然后在 D2H 响应通道上发送 RspIHitSE。RspI 表示其最终缓存状态为 I 状态，HitSE 表示缓存在降级为最终 I 状态之前为 S 或 E 状态。

一致性协议的一个重要组成部分是如何处理对同一地址的冲突访问。有两种情况值得强调：(1) Req-to-Snoop 和 (2) Eviction-to-Snoop。要解决 Req-to-Snoop 情况，H2D 响应通道上的 GO 消息必须排在对同一高速缓存行地址的任何未来 Snoop 之前，以确保设备在处理 Snoop 之前观察主机提供的高速缓存状态（如有）。其原因如图 7(a) 所示，主机发送的 GO 消息必须在后面的窥探之前被观察到，这样设备才能意识到它已独占了该地址的所有权，并能正确处理窥探。图 7(b) 是顺序相反的情况，即主机首先处理窥探，并在窥探完成前停止处理未来的请求，因此设备在 GO 之前观察到窥探会导致在缓存处于无效状态时处理窥探。就 Evict-to-Snoop 而言，图 7(c) 显示了当 DirtyEvict 未处理时 snoop 到达的情况，设备必须用当前的 M 状态数据回复 snoop。稍后的 GO_WritePull 仍必须返回数据，但包括数据是假的（意味着可能是过期数据）的提示，因此主机必须放弃数据，因为更新的数据可能存在于其他代理中。

3.5CXL.mem 协议

内存协议使设备能够公开主机管理的设备内存（HDM），允许主机管理和访问该内存，类似于连接到主机的本地 DDR。该协议独立于内存媒体，使用一组简单的主机物理地址2 读取和写入，要求设备内部转换为设备的媒体地址空间。该协议固有的 CXL 附加内存容量是有限的；实际上，限制来自于可附加 CXL 设备的数量和大小。对于希望同时缓存该内存的加速器设备，提供了高级语义，使设备能够直接缓存内存，并依靠设备跟踪主机对该内存的缓存。

该协议在每个方向上使用两个通道，分别称为主控对从属（M2S）和从属对主控（S2M）。M2S 方向提供一个请求通道和一个带数据的请求（RwD）通道。S2M 方向提供非数据响应（NDR）通道和数据响应（DRS）通道。为了实现简单/低延迟，通道之间没有排序。

CXL.mem 的两种使用情况是 (1) 作为 "主机内存扩展器"，(2) 作为暴露给主机的加速器内存。两者都使用 HDM 术语来描述 CXL.mem 协议访问的内存区域，但协议要求有所不同。为了识别这些要求，后缀"-H "修饰符（HDM-H）表示主机内存扩展器是 "仅主机一致性 "的，"-D "修饰符（HDM-D）表示暴露给主机的加速器内存是 "设备管理一致性 "的3 HDM-H不包括任何一致性协议假设，而HDM-D包括每个报文中使用的高速缓存状态和高速缓存窥探属性。HDM-D 还需要一种方法，用于从设备向主机传送所需的内存高速缓存状态，称为 "偏置翻转 "流（Bias Flip Flow）4。

HDM-H 可选为每个高速缓存行提供 2 位元值，供主机使用。可能的用途包括一致性目录、安全属性或数据压缩属性。图 8(a) 显示了一个示例流程，主机读取更新设备中的元值，设备返回元值的先前状态。在此示例中，设备需要更改存储在设备中的当前元值，因为值已从 2（旧值）变为 0（新值）。请注意，内存介质存储的元值和 ECC（纠错码）位是针对特定设备的。

图 8. CXL 1.1 内存协议流程。

HDM-D 使用元值字段的方式不同，它在该字段中向设备公开主机一致性状态，这样设备就能知道主机为 HDM-D 区域中的每个地址缓存的状态。本规范使用 "设备一致性 (DCOH) 代理 "一词来描述设备中管理/跟踪设备与主机之间一致性的代理。图 8(b) 显示了 HDM-D 的一种情况，即主机在 S 状态下向高速缓存读取数据，并要求设备检查其高速缓存（Dev ∃）的当前副本，但在本例中，高速缓存中没有数据，因此数据是从主机内存中传送的。

HDM-D 一致性模型允许设备使用 CXL.cache 请求改变主机状态。CXL.cache 是实现这一功能的自然方式，因为 HDM-D 仅针对类型 2 进行了定义。设备改变主机高速缓存状态的流程被称为 "偏置翻转 "流程。图 9 是该流程的一个示例。设备向主机发送 "RdOwnNoData X"。主机检测到地址 X 是由发出设备拥有的 HDM-D 地址，其行为将与原来不同，因为它会直接改变主机的缓存状态，迫使所有主机缓存进入 I 状态。偏置翻转 "流的响应与传统的 CXL.cache 响应不同，在本例中，主机将在 CXL.mem M2S Req 信道上发送响应 MemRdFwd 消息，以表明主机已完成缓存状态更改。通过使用 CXL.mem M2S Req 通道，可以避免与主机之间的竞争条件，因为未来对同一地址的 CXL.mem 请求要求 M2S 请求通道排序才能访问同一高速缓存行。排序要求仅适用于 HDM-D 地址。

图 9. HDM-D 偏置翻转流程。

3.6协议层次

CXL 与 CPU 内部的一系列一致性实现兼容。图 10(a)捕捉了一个可能的主机 CPU，其中 CXL.cache 位于与 CPU 内核共享的主机 L3 cache 下。在此示例中，CXL.io/PCIe 协议访问主机内存时也会通过相同的高速缓存，并遵循主机内存路径上使用的目标一致性语义。本图显示的是插座中的单个 L3。另外，主机架构也可以拆分 L3 或其他内部高速缓存，但不会对 CXL.cache 产生影响，因为 CXL.cache 不了解主机高速缓存的详细信息。根据主机特定协议（专有 CPU-to-CPU）的定义，主机可扩展到多个 CPU 插座或高速缓存，该协议定义了一个内部主代理，以解决主机高速缓存（包含 CXL.cache 设备）之间的一致性问题。该主机主代理可包括用于解决一致性问题的主机特定优化，如片上窥探过滤器或内存目录状态。CXL.mem 协议位于主机主代理逻辑之后，可支持仅主机一致性（HDM-H）或设备一致性（HDM-D）的简单内存扩展。对于 HDM-D，在主机主代理之后还包括一个额外的一致性解决级别，允许设备成为设备所拥有地址一致性的最终仲裁者。

图 10. CXL 协议层次结构。

图 10(b) 显示了 CXL 中预期的协议依赖图。协议依赖图定义了哪些协议通道可能会被其他协议通道依赖（或阻塞）。如果没有产生循环依赖关系，依赖关系图是显示通道间死锁自由度的一种方法。依赖关系图中的一个例子是，L1 Req 可能依赖于 L1-Snp 通道完成，然后才能处理新的 L1 Req。之所以存在这种依赖关系，是因为请求可能需要先发送并完成窥探，然后才能完成请求。L1 协议是 CXL.cache 中提供的通道的抽象，其中 L1-Req 映射到 D2H Req，L1-Snp 映射到 H2D-Req，L1 RSP 映射到 H2D/D2H RSP 和数据通道，这些通道已预先分配给主机或设备，从而将这两个通道结合起来，形成依赖关系图。L2 协议是针对主机的，以主机可能存在的通道为例，但也可以选择其他通道。如果依赖关系图不存在循环，主机还可以包含其他级别的协议。L3 协议为 CXL.mem，其中 L3 Req 映射到 M2S-Req，L3-RwD 映射到 M2S-RwD，而 L3-Rsp 则覆盖预分配的 S2M NDR 和 DRS 信道。依赖关系图是一种用于显示协议中和协议间的法律关系和依赖关系的方法，可快速确定 CXL 本身以及主机或设备内部协议选择的高级死锁自由度。

   4 CXL 2.0 协议   

CXL 第二代实现了资源池功能，可在一段时间内将相同的资源分配给不同的主机。在运行时重新分配资源的能力解决了资源搁浅问题（第 1 节中的挑战 3），因为它克服了资源与单个主机之间的紧密耦合。如果一台主机运行计算密集型工作负载，但没有使用从池中分配的设备内存，那么操作员可以将该设备内存重新分配给另一台主机，后者可能运行内存密集型工作负载。由于操作员在设计时通常不知道哪些工作负载在哪些主机上运行，因此资源池可以节省大量内存： 操作员无需根据任何类型的内存密集型工作负载所使用的最坏情况内存容量来确定两台主机的大小，而是根据平均情况提供内存。同样的池结构也适用于加速器等其他资源。

4.1 CXL 2.0 协议增强功能

CXL 2.0 增加了热插拔、单级交换、内存 QoS、内存池、设备池和全局持续刷新（GPF）。CXL 1.1 不允许热插拔，这就排除了在平台启动后添加 CXL 资源的可能性。CXL 2.0 支持标准 PCIe 热插拔机制，实现了传统的物理热插拔和动态资源池。

为支持单级切换，CXL 对 HDM 解码器中 CXL.mem 地址区域的地址解码进行了标准化。分层解码遵循 PCIe 内存解码模型，允许在每个交换机上进行解码，避免主机或交换机对分层中的所有代理进行完全解码。为支持多主机连接并启用设备池，每台主机都将 CXL 拓扑表示为一个虚拟层次结构（VH），其中包括交换机、主机端口的虚拟网桥以及具有设备资源的每个端口。如图 11 所示，每台主机都会看到一个单独的 VCS（虚拟 CXL 交换机），其中包括分配给该主机的设备的网桥。流量会根据 VH 中的活动虚拟网桥路由到设备。这就限制了 CXL 2.0 的有向树拓扑结构，每个主机和设备之间最多只有一条路径。此外，由于需要在交换机中跟踪每个 VH 的地址映射，CXL 3.0 克服了这一限制（第 5.4 节）。配置和更改 VH 将在第 4.2 节中介绍。

图 11. 具有两个虚拟层次结构的 CXL 交换机示例。

设备池建立在多主机交换机支持的基础上，允许设备一次动态分配给一台主机。标准设备一次分配给一台主机，称为单逻辑设备（SLD）。CXL 还定义了多逻辑设备（MLD），允许将单个 CXL.mem 设备的资源划分为逻辑设备（最多 16 个），同时分配给不同的主机。MLD 中的每个逻辑设备都可分配给不同的主机。CXL 3.0 引入了名为 "动态容量设备 "的扩展，灵活性更高。MLD 中的每个逻辑设备 (LD) 都由一个标识符 (LD-ID) 标识。这种扩展只在交换机和设备之间的链路上可见，主机看不到。主机将 LD-ID 字段留空。CXL 交换机根据主机端口将 LD-ID 标签应用于主机的 CXL.io 和 CXL.mem 事务。

由于交换、MLD 和潜在的不同类型内存（可能不是基于 DRAM），单个交换机中的资源可能会被过度占用，从而导致 QoS 问题。例如，一台设备的低性能可能会导致使用交换机的所有代理出现拥塞。为缓解这一问题，CXL 2.0 在 CXL.mem 响应信息中引入了 DevLoad 字段，以告知主机在其访问的设备中观察到的负载。主机应使用此负载信息来降低向该设备发送 CXL 请求的速率。CXL 规范定义了一个参考模型，即在高负载或临界负载时降低注入速率，直到达到额定负载；在轻负载时，主机可提高注入速率，直到达到额定负载。

如果有多个 CXL 请求注入点（例如，在 CXL 2.0 池方案中），则通过源节流提供 QoS，控制每个源可消耗多少 MLD 资源。对于非共享资源，可通过确保不同 VH（或 PBR 目的地）的事务能够在不相互依赖的情况下进行，来隔离每个 VH。CXL 协议还定义了一个遏制模型，确保如果端点设备没有响应，受影响的 VH 将通过对主机内未完成的访问生成错误响应来遏制错误，以避免主机超时，否则可能导致 VH 故障。

CXL 还定义了内存设备的错误报告，包括毒药数据支持。虽然确切的纠错码取决于内存介质的类型以及使用模式和平台，但对已纠正的错误和已检测到但未纠正的错误都进行了报告定义。报告已标准化，以便软件采取必要的措施。

4.2 设备库管理

池管理是指在运行时将 CXL 设备分配给主机。该标准使用术语 CXL Fabric Manager (FM) 来表示做出分配决策的应用逻辑和策略。实际上，FM 可以是主机上运行的软件、嵌入在底板管理控制器 (BMC) 或 CXL 交换机内的固件或专用设备。FM 通过使用组件命令接口 (CCI) 将（逻辑）设备分配给主机。这既可以在带内进行，例如通过内存映射输入/输出（MMIO），也可以通过管理组件传输协议（MCTP）在带外进行。MCTP 支持多种带外通信，包括 SMBus/I2C、PCIe、USB 和串行链路。

FM 通过绑定命令将设备分配到主机，该命令需要四个参数：CXL 交换机 ID、虚拟网桥 ID、物理端口 ID 和逻辑设备 ID（SLD 为空）。FM 将此命令发送到指定的交换机，交换机会检查该物理端口当前是否未绑定。如果未绑定，交换机将更新其内部状态以执行绑定。然后，它会向主机发送热添加指示，最后通知 FM 绑定成功。虚拟网桥和相关设备现在出现在主机的虚拟层次结构中。图 11(a) 和图 11(b) 之间显示了这种过渡。

对于 MLD，FM 可能需要首先通过 Set-LD 命令配置逻辑设备。该命令根据内存粒度（如 256 MB）和多个内存范围创建 LD。当 FM 没有与 MLD 的带外连接时，可通过 CXL 交换机传输该命令。创建 LD 后，FM 可以使用绑定命令将其分配给一台主机，并使用相应的 LD-ID 进行绑定。

要撤销设备分配，FM 可使用 unbind 命令，该命令需要三个参数：CXL 交换机 ID、虚拟网桥 ID 和 unbind 选项。解除绑定选项表示如何执行解除绑定，包括等待主机停用端口、热移除并等待主机或强制热移除。利用最后一个选项，FM 可以处理不合作的主机，例如由于故障或分配给裸机云中的第三方客户的主机。

除了这里介绍的三种命令外，FM 还支持 19 种其他命令。它们包括 QoS 控制，如在 MLD 内的逻辑设备之间分配带宽。这些命令还包括识别交换机端口和设备以及查询和配置其状态的方法（参见参考文献中的表）。

4.3 主机软件支持

尽管大部分 CXL 都是在主机外部的硬件和软件（如调频）中实现的，但主机软件在支持 CXL 方面仍发挥着重要作用。在高层次上，系统固件会枚举和配置启动时存在的 CXL 资源。操作系统（OS）枚举和配置运行时连接和分离的 CXL 资源，例如热添加和热删除的内存地址范围。因此，操作系统在支持 CXL 2.0 方面发挥着重要作用。

传统上，资源拓扑和亲和性通过静态 ACPI（高级配置和电源接口）表进行通信。例如，NUMA（非统一内存访问）域在 SRAT（静态资源亲和表）表中定义，内存带宽和延迟在 HMAT（异构内存属性表）表中定义。通常情况下，这些表由固件配置，固件在启动时了解所有资源5。在 PCIe 中，这个问题比较简单，因为插入设备不会影响系统映射的内存。而在 CXL 中，需要为运行时连接的内存传递特定于内存的资源特性。在 CXL 供应商和设备的生态系统中，事先定义配置是不可行的。CXL 2.0 引入了相干设备属性表（CDAT），该表描述了内部 NUMA 域、内存范围、带宽、延迟和内存使用建议。当内存（逻辑）设备在运行时被热添加时，主机会读取相关的 CDAT 寄存器，操作系统会分配一个空闲的 HPA（主机物理地址）范围，并对 HDM 解码器进行编程。

文章来源：半导体行业观察