CXL 三大子协议：CXL.io、CXL.cache、CXL.mem 的功能与区别
做 CXL 系统，绕不开三个子协议。很多人刚接触时，总觉得它们就是 PCIe 加了个缓存协议。其实远没那么简单。CXL.io、CXL.cache、CXL.mem，这三者各管一摊，又必须协同工作。我刚开始带项目时，也把它们的职责搞混过，结果硬件验证阶段出了不少问题。今天咱们就把这三兄弟彻底捋清楚。
CXL.io：基础传输与控制平面
说白了，CXL.io 就是 CXL 的基础骨架。它复用了 PCIe 的物理层和数据链路层，向上提供与 PCIe 一致的事务层接口。你想想看，既然是跑在 PCIe 的电气接口上，那基本的设备发现、配置空间访问、中断路由、错误上报这些活，全归 CXL.io 管。
- 负责设备的 枚举 和 热插拔 流程
- 处理 MMIO 访问：主机读写设备的控制寄存器
- 承载 MSI/MSI-X 中断消息
- 处理与 DVSEC（Designated Vendor Specific Extended Capability）相关的配置
我在项目中遇到过一件事：一颗 CXL 内存扩展器在 BIOS 阶段怎么也枚举不出来。查了两天，最后发现是 CXL.io 链路上的 DVSEC 解析逻辑没对齐，导致主机认为该设备不支持 CXL。你看，基础的东西反而最容易出问题。
CXL.cache：设备主动缓存协议
CXL.cache 是做什么的？它允许设备主动缓存主机的内存。这个“主动”很关键。传统 PCIe 设备只能被动地被主机读写，但有了 CXL.cache，设备可以自主决定缓存哪些主存行，还能发起 snoop 来保证一致性。
为什么需要这个？
- 加速设备访问频繁数据：比如智能网卡处理流表时，把热点条目缓存在本地
- 减少访问主存的延迟：设备直接读自己的缓存，不用每次穿过 PCIe 去拿
- 实现 CPU 和设备共享数据结构的低延迟互访
CXL.cache 的核心操作有三类：Cache Request（设备发起）、Snoop Request（主机发起）、Cache Writeback（设备回写脏数据）。我习惯把 CXL.cache 理解成“设备侧的 L4 缓存”——它跟 CPU 的 Cache 遵循同一套一致性协议。
嗯，这里要注意：CXL.cache 不是随便哪个设备都能用的。它要求设备端具备完整的 snoop 过滤和缓存一致性状态机。我记得有个团队评估了一款第三方 CXL 控制器 IP，结果发现它的 CXL.cache 状态机实现有缺陷，在一些边界场景下会丢 snoop 响应。后来只能降级只用 CXL.mem。
CXL.mem：主机访问设备内存
CXL.mem 解决的是另一个方向的问题——主机如何访问设备上挂载的内存。比如你插了一根 CXL 内存扩展卡，主机 CPU 怎么读到它上面的数据？就是靠 CXL.mem。
CXL.mem 本质上是一个内存语义的传输协议。它定义了：
- 主机发起的内存读/写请求（MemRd / MemWr）
- 设备返回内存数据（MemData）
- 可选的预取和一致性回写操作
CXL.mem 的厉害之处在于，它允许将设备内存纳入主机的统一内存地址空间。你想想看，主机可以直接 load/store 访问设备内存，就像访问本地 DRAM 一样。延迟当然比本地内存高一点，但比通过 NVMe 等块设备要快几个数量级。
| 对比维度 | CXL.io | CXL.cache | CXL.mem |
|---|---|---|---|
| 用途 | 控制、配置、中断 | 设备缓存主机内存 | 主机访问设备内存 |
| 协议层 | 基于 PCIe 事务层扩展 | 独立的一致性协议层 | 独立的内存语义协议层 |
| 主要操作 | CFG Rd/Wr, MMIO, MSI | CacheReq, SnpReq, WB | MemRd, MemWr, MemData |
| 事务类型 | 非一致性的控制类事务 | 完全一致性事务 | 一致或非一致性（依配置） |
| 是否支持设备缓存 | 否 | 是（核心功能） | 否（但可配合 CXL.cache） |
| 典型延迟 | 微秒级（MMIO） | 纳秒级（本地缓存命中） | 亚微秒级（跨链路） |
你可能会问：有了 CXL.cache 为什么还要 CXL.mem？反过来也一样。答案是，它们解决的是不同场景：CXL.cache 是设备“拉”数据到本地，CXL.mem 是主机“推”数据到设备内存。一个典型的混合场景是：智能网卡用 CXL.cache 缓存频繁匹配的流表项，同时通过 CXL.mem 把大块报文直接写入主机可寻址的扩展内存池中。
核心观点：三大子协议不是相互替代的关系，而是互补的。CXL.io 管连接和配置，CXL.cache 管设备侧的一致性缓存，CXL.mem 管主机侧的内存扩展。三者在一条物理链路上同时运行。
三者的协作关系
在真实的 CXL 链路上，这些协议是交织在一起的。比如设备启动时，第一件事是通过 CXL.io 做配置和握手；确认支持 CXL.cache 或 CXL.mem 后，再建立对应的协议层连接。
我从验证角度给你一个建议：写 testplan 时，先把 CXL.io 的基础枚举和配置跑稳，再叠加 CXL.cache 的一致性乱序或 CXL.mem 的带宽压力。否则问题混在一起，定位起来相当头疼。我曾经在一个项目里，CXL.mem 的写错误和 CXL.io 的中断丢失同时出现，查了一周才确认是两个独立的 bug。