第3章 CXL协议架构：CXL.io, CXL.cache, CXL.mem
讲CXL，绕不开它那三个子协议。很多人刚接触时会懵——这三个东西到底怎么分工？我当年也花了些时间才理清楚。今天咱们就把它彻底掰开揉碎。
CXL协议栈不是一个大一统的怪物，而是分成了三条独立但又协作的通道。你想想看，如果所有通信都挤在同一条路上，延迟和争用根本没法控制。所以CXL设计了三个专用通道：CXL.io、CXL.cache和CXL.mem。它们跑在同一条PCIe物理链路上，但逻辑上各干各的活。
3.1 三驾马车各自负责什么
我用一句话概括：CXL.io是控制面，CXL.cache是缓存面，CXL.mem是内存面。听起来抽象？我们逐个拆。
| 子协议 | 核心职责 | 典型场景 |
|---|---|---|
| CXL.io | 设备枚举、配置、中断、DMA、I/O语义 | 发现设备、分配地址、处理错误 |
| CXL.cache | 请求CPU缓存行，维护缓存一致性 | 加速器读取/修改CPU缓存数据 |
| CXL.mem | 直接访问系统内存，类似RDMA但更轻量 | GPU/NPU直接读写主机DRAM |
重要提醒：三个子协议共享同一物理链路，但逻辑上完全独立。硬件通过复用仲裁，软件通过单独的虚拟通道来区分。实际实现时，CXL.io是必选项，CXL.cache和CXL.mem可按需组合。
我个人习惯把CXL.io看作“后台管家”——他负责处理所有杂事：设备上电、配置空间访问、MSI中断、I/O地址映射。没有它，其他功能都跑不起来。而CXL.cache和CXL.mem才是真正干活的“前台明星”。
3.2 CXL.io——不可或缺的老黄牛
CXL.io本质上复用了PCIe的Transaction Layer，但加了几个CXL特有的消息类型。说白了，它就是用PCIe物理层跑CXL控制协议。你在PCIe规范里见过的配置写、配置读、完成包、中断，在CXL.io里都有，只是多了D2H/H2D消息用来协商CXL能力。
我在项目里遇到过一个问题：一个加速器卡插上去后，主机始终找不到它的CXL能力寄存器。折腾了半天才发现是CXL.io的Vendor Defined Message没有正确实现。嗯，这里要注意——CXL.io的初始化握手比普通PCIe多了几步，设备必须在Link Training之后发一个CXL_CAPABLE消息，否则主机以为你只是个普通PCIe设备。
// CXL DVSEC能力寄存器（每个CXL设备必须实现）
// 位于PCIe配置空间，Vendor ID = 0x1E98
Offset 0x00: CXL DVSEC Capability Header
Offset 0x04: CXL DVSEC Capability Register
Offset 0x08: CXL DVSEC Control Register
Offset 0x0C: CXL DVSEC Status Register
// 具体字段定义见CXL 3.0 Spec Section 7.1.1
3.3 CXL.cache——缓存一致性搬运工
CXL.cache是三个里面最“聪明”的。它允许一个设备（比如智能网卡、AI加速器）直接请求CPU缓存中的数据。注意，不是通过内存，而是直接打到CPU的L2/L3 Cache。这意味着加速器可以读到最新的、没有被写回内存的数据。
CXL.cache定义了几种事务：Snoop、Read、Write、WriteUnique、WriteEvict。每个事务都会触发CPU侧的缓存探听。我见过不少开发者想当然地用CXL.mem处理所有数据交换，结果发现延迟不对——他们完全忽略了CXL.cache特有的缓存命中延迟优势。
实战技巧：如果你的加速器需要频繁读取CPU刚刚修改的热数据，请优先考虑CXL.cache。反之，如果加速器只需要大量顺序读取冷数据，CXL.mem更合适。我曾在一个AI训练场景里用CXL.cache把推理时延砍掉了30%。
3.4 CXL.mem——内存池化的发动机
CXL.mem最直接、也最容易理解。它让设备可以像访问自己的本地内存一样访问系统内存。本质上就是做了一个地址转换：设备发出物理地址，CXL控制器通过MMIO窗口映射到主机DRAM。
CXL.mem支持两种访问方式：Host Coherent和Device Coherent。前者保证CPU和设备看到一致的视图，后者允许设备有自己独立的缓存，但需要软件保证一致性。我建议新手直接用Host Coherent模式，省心。但代价是每次访问都需要走一遍CPU一致性协议，延迟会略高。
CXL.mem的性能关键在延迟和带宽。记得有一次测CXL.mem延迟，怎么都压不到标称值。后来发现是BIOS里把CXL的RC（Root Complex）配置成了Non-Coherent模式。改回来以后延迟直接降了一半。所以说，硬件配置坑很多。
3.5 三个协议如何配合工作
光说概念不过瘾，我们看看实际流中它们怎么协作。下面这张图是我根据自己项目理解画的，你看完应该能明白它们的层次关系。
从图中能清楚看到：所有数据都经过CXL Root Complex，它把来自设备的上行请求路由到对应的子协议处理。CPU看到的是三个独立的接口，但实际上物理层只有一条管道。
3.6 避坑与实战建议
- CXL.io必须最先初始化。只有CXL.io正常工作后，CXL.cache和CXL.mem才能开始通信。我曾经在调试时忘记检查CXL.io的握手状态，结果cache事务一直超时。浪费了两天。
- CXL.cache的Snoop Filter很重要。如果设备频繁无效化CPU缓存行，性能会下降。建议通过DVSEC寄存器确认Snoop Filter的大小和使能状态。
- CXL.mem的写策略要选对。写穿透（Write Through）和写回（Write Back）各有优劣。Write Through保证安全但带宽低，Write Back性能好但需要设备缓存一致性。我建议做芯片验证时先用Write Through排错。
- 虚拟通道（VC）不能混用。CXL.io用VC0，CXL.cache用VC1，CXL.mem用VC2。设备必须严格遵从，否则链路层会丢包。
警告：市面上一些早期的CXL 1.0实现不支持CXL.cache和CXL.mem同时启用。如果你买的是旧款FPGA加速卡，务必查清其能力位（CXL Capability Register bit[1:0]），否则可能遇到莫名其妙的不一致性错误。
好了，CXL协议架构的三条腿我们讲完了。下节课咱们会深入CXL.io的初始化流程，包括链路训练后的DVSEC协商——那一步才是真正区分CXL设备与普通PCIe设备的分叉口。记住今天这张图，后面都会用到。