1. CXL.cache 协议概述与发展背景
1.1 什么是 CXL.cache
CXL.cache 是 CXL 协议栈里负责缓存一致性的子协议。说白了，它让 CPU 的私有缓存和外接加速器（比如 FPGA、AI 芯片）的本地缓存能相互“看得见”，不会出现数据打架。
我刚开始接触 CXL 的时候，以为它就是个高速 PCIe。后来才发现，CXL.cache 才是这套协议最核心的卖点——它让加速器可以像 CPU 自己的核心一样，直接读写 CPU 的缓存行，而不需要软件管数据同步。嗯，这里要注意，CXL.cache 只处理一致性域的通信，真正的数据传输走 CXL.mem 或 CXL.io。
1.2 为什么需要 CXL.cache
传统 PCIe 设备跟 CPU 共享数据，通常靠 DMA 加轮询或者中断。你想想看，每次加速器要读一个变量，都得先通过 DMA 搬到自己内存里，然后软件通知 CPU 缓存失效——这种流程延迟高、带宽浪费，而且一致性维护全靠软件，容易出错。
我在一个 AI 推理项目里遇到过这种坑。加速器算完一批数据，CPU 侧的缓存还是旧值，结果推理结果全错。后来排查了两天才发现是缓存一致性问题。当时我就想，如果有硬件帮我们维护一致性就好了——CXL.cache 就是干这个的。
- 降低延迟：加速器直接请求 CPU 缓存行，绕过系统内存。
- 减少软件开销：硬件自动做 cache coherence snoop 和 invalidation。
- 支持更细粒度共享：以 64B 缓存行为单位操作，不是整页 DMA。
1.3 CXL.cache 与 CXL.mem、CXL.io 的关系
CXL 协议族分三层，大家常说的“CXL”其实是这三层打包在一起。我习惯用一个表格把它们区分开：
| 子协议 | 主要职责 | 典型场景 |
|---|---|---|
| CXL.io | 设备发现、配置、中断、非一致性的 I/O 访问 | 寄存器编程、控制路径 |
| CXL.cache | CPU 与设备之间缓存一致性请求/响应 | 加速器读写 CPU 缓存行 |
| CXL.mem | 设备访问系统内存（或主机访问设备内存）的语义 | 共享内存池、内存带宽扩展 |
CXL.cache 和 CXL.mem 经常配合使用。比如加速器想读一个 CPU 已经缓存的数据：CXL.cache 先发 snoop 请求让 CPU 把缓存写回，然后 CXL.mem 再发起内存读取。它们俩走的是同一条物理链路，但在逻辑上是独立的事务通道。
1.4 发展背景与标准化历程
CXL 1.0 在 2019 年由 Intel 联合多家厂商推出，当时主要解决加速器缓存一致性问题。我记得 CXL 1.0 只支持对称一致性——设备和 CPU 角色对等，都能做 home agent 和 slave。后来 CXL 2.0 加了内存池化和多逻辑设备（MLD），CXL 3.0 更是引入了交换机和 Fabric 架构。
- CXL 1.0/1.1：基本缓存一致性，基于 MESI 衍生协议，单链路。
- CXL 2.0：支持单根多设备、内存池，增强了 QoS。
- CXL 3.0：多根互联、Fabric 级一致性、单跳多目标。
为什么 CXL.cache 能在大量厂商中快速落地？因为它不改变 CPU 内部一致性协议（如 Intel 的 MESIF 或 AMD 的 MOESI），只在外设侧做了适配。我曾经跟一位 CPU 架构师聊过，他说“CXL.cache 本质上是在 SoC 的管道上开了个口子，让外设也能参与 snoop 广播”。这个比喻很形象。
1.5 CXL.cache 核心概念——Snoop Filter 与 Coherence Engine
要实现缓存一致性，关键有两个硬件单元：
- Snoop Filter（侦听过滤器）：记录每个缓存行的 owner。加速器发请求时，主机侧的 snoop filter 判断该行是否在其他 CPU 缓存中，决定要不要发 snoop。
- Coherence Engine（一致性引擎）：负责状态机迁移（M/E/S/I 状态转换），处理冲突和响应排序。
我在调试一个 CXL 设备时遇到过一个问题：加速器写了一个缓存行，但 CPU 那边的 snoop filter 没更新，结果 CPU 读到了旧数据。最后发现是 Coherence Engine 的写响应顺序没处理好——设备必须先等 snoop 完成再更改本地缓存。这是个典型的时序陷阱。
下面这张 SVG 图展示了 CXL 协议的三层架构，以及 CXL.cache 在其中的位置：
从图中可以清楚看到，CXL.cache 位于协议栈中间层，向上对接主机侧的 Snoop Filter 和 Coherence Engine，向下依赖 PCIe 物理层。我在实际调试时，经常先确定问题出在 CXL.cache 事务层（比如请求类型错误）还是 链路层（CRC 或重传问题），这样可以快速定位。