2. CXL体系架构总览：从系统视角看CXL组件与层次结构

好，我们开始第二章。上一章我们聊了CXL是什么、为什么重要。这一章，我们把视角拉高，从整个系统的角度看CXL的骨架。

说白了，你得先知道CXL这个房子有几层楼、每层住着什么角色，后面调试代码、排查性能问题才不会迷路。我习惯把CXL的体系架构拆成三个视角来看：物理层面（谁连谁）、协议层面（怎么通信）、事务层面（传什么东西）。

2.1 物理组件：谁跟谁连在一起？

一个典型的CXL系统里，你会看到三类核心角色。这三类角色构成了CXL的物理骨架。

• Host（主机/CPU）：通常是x86或ARM的SoC。它内部集成了CXL控制器和Root Complex。主机是发号施令的一方。
• Device（设备/加速器）：可以是智能网卡、GPU、FPGA或专用的内存控制器。设备响应主机请求，也能主动发起请求。
• Switch（交换器/重定时器）：当设备多了，就需要Switch来扩展拓扑。它负责数据包的转发和路由。

我有个建议——刚开始不要被“CXL vs PCIe”搞晕。你只要记住：PCIe是快递员，CXL是给快递员配了把钥匙。快递员还是那个人（物理层），但CXL让他能直接进你家（CPU内存系统）了。

2.2 协议层次：三层栈的逻辑划分

这部分是重点中的重点。CXL协议栈在逻辑上分了三层。我画个图帮你理解。

你看，三层结构非常清晰。从上到下依次是：

1. 事务层：决定传输什么样的“语义”——是读内存、写设备寄存器，还是缓存一致性消息。
2. 链路层：负责确保数据可靠传输。它加CRC、处理重传。嗯，这里要注意，CXL链路层比PCIe多了很多精巧的流控机制。
3. 物理层：跟PCIe共用。所以所有CXL训练出来，链路的速率、宽度都和PCIe一致。

2.3 三种协议复用：CXL.io / CXL.mem / CXL.cache

这是CXL创新最核心的地方。一条物理链路上，跑了三种完全不同的“方言”：

协议类型	主要用途	类比说明
CXL.io	设备发现、配置、中断、DMA	跟PCIe完全兼容，就像普通的出租车
CXL.mem	主机直接访问设备内存（内存语义）	像把设备的内存插到CPU总线扩展槽里
CXL.cache	设备访问主机缓存并保持一致性	设备变成了CPU的“兄弟核”

.io协议，说白了就是PCIe换了个马甲。你写一个PCIe驱动，可以直接驱动CXL.io部分。这也是为什么Linux内核在枚举CXL设备时，会看到一个标准的PCIe配置空间——背后就是.io协议在支撑。

「那.mem和.cache呢？」

我记得刚接触CXL时，这个让我纠结了很长时间。后来我摸到了规律：.mem负责“内存数据移动”，.cache负责“一致性握手机制”。这两者往往配合使用。

举个例子：一个CXL内存扩展设备。主机通过.mem直接读写设备的内存，就像访问本地内存一样。但问题是——主机可能已经在缓存里有了旧的数据副本。这时就需要.cache协议来发一个“使无效”或“清洗”的消息，确保设备拿到的是最新值。

2.4 拓扑与层级：从1:1到多层级组织

CXL的拓扑有几种经典形态。我按照复杂度排个序：

• Type 1 / Type 2 / Type 3 设备：这是最基础、最常见的形式。Type 1只支持.cache（比如特定加速器），Type 2同时支持.mem和.cache（比如带缓存的GPU），Type 3只支持.mem（纯内存扩展）。
• 1:1 直连：CPU直连一个CXL设备。内部集成或通过Riser卡。延迟最低。
• Switch 连接：一个CPU连一个CXL Switch，再挂多个设备。常见于数据中心机架。
• 多级Switch：复杂拓扑，支持大集群部署。CXL 3.0开始正式支持多级结构。
• 内存池化：多个主机共享一个内存池。这是CXL 2.0/3.0的杀手特性。

拓扑类型	CXL 1.1/2.0	CXL 3.0
单级Switch	✔️	✔️
多级Switch	❌ 不支持	✔️ 原生支持
内存池化	✔️ 需限定	✔️ 原生、高效
Fabric直连	❌	✔️ 支持

2.5 系统视角的要点总结

好，这一章的核心内容差不多讲完了。做个小结，帮你拎清楚：

• 物理组件：Host、Device、Switch，这三兄弟组成了一个灵活的拓扑。
• 三层协议栈：事务层（定语义）→ 链路层（保可靠）→ 物理层（传电信号）。
• 三种协议复用：.io（兼容）、.mem（直访内存）、.cache（保一致）。
• 系统拓扑：从单点直连到多级Switch再到内存池化，CXL正在一步步打通整个数据中心的内存网络。