2. CXL.cache 一致性模型介绍
大家好，今天我们聊聊 CXL.cache 的核心——它的一致性模型。
很多做 PCIe 出身的朋友，刚接触 CXL 时容易懵。你想想看，PCIe 只是一个纯 IO 协议，设备访问主机内存需要 DMA，根本不管什么缓存一致性。但 CXL.cache 不一样，它允许设备（比如加速器、智能网卡）直接把自己内部的缓存，跟 Host 的缓存和内存联动起来。说白了，就是把外部设备当成 CPU 的一个“缓存代理”来协同工作。
2.1 从宏观视角看 CXL.cache 的位置
CXL 协议簇分为三部分：CXL.io、CXL.cache、CXL.mem。
我个人习惯用这张表来帮团队新人定位：
| 协议通道 | 主要作用 | 类比 PCIe 术语 |
|---|---|---|
| CXL.io | 设备枚举、配置、中断、MMIO 访问 | PCIe 的 Non-Transparent Bridge（NTB） |
| CXL.cache | 设备主动缓存 Host 内存，发起 snoop 请求 | 类似 CPU 核心之间的 Cache Coherency |
| CXL.mem | 设备直接访问 Host 内存（好比本地内存） | 类似 DDR 内存控制器接口 |
理解这个分层很重要。CXL.cache 不是替换 CXL.mem，它们可能在一条物理链路上共存。我记得在一次原型验证中，靠 CXL.cache 做设备端缓存命中加速，靠 CXL.mem 处理大块数据搬迁——两条通道配合好，延迟可以压到纳秒级。
2.2 CXL.cache 的两种缓存模型
本质上，CXL.cache 定义了两种角色：宿主（Host）和设备（Device）。
- Host 负责维护全局内存一致性目录（Snoop Filter 或 Directory）。
- Device 维护自己内部的缓存行，通过 Request 和 Response 与 Host 交互。
根据 Device 是否能够缓存数据且拥有“唯一权限”，CXL.cache 区分了两个模型：
| 模型 | 设备缓存属性 | 典型场景 |
|---|---|---|
| Host-managed | 设备只能缓存非唯一副本（Shared 或 I 状态） | 偏向于纯加速器，不需要独占缓存行 |
| Device-managed | 设备可以独占总线状态（E/M 状态，类似 CPU 核心） | 智能网卡或 FPGA 需要本地修改数据 |
为什么会有这个区分？因为 MESI 放在设备侧风险和收益并存。Device-managed 可以大幅减少 Host 端的 snoop 流量，但如果设备的状态机设计不严谨，很容易产生死锁或数据不一致。我个人建议刚接触 CXL.cache 的团队，先从 Host-managed 模型起步，等状态机调试熟练后再切换到 Device-managed。
2.3 核心一致性协议：MESI（like）
CXL.cache 用的协议跟 CPU 内部缓存一致性协议很像，但做了裁减。它主要定义四个状态，我把它们的含义整理成表格：
| 状态 | 设备是否有副本 | 设备是否可修改 | Host 侧对应处理 |
|---|---|---|---|
| M (Modified) | 唯一副本，已修改 | 是 | Host 无有效副本，设备写回时 Host 才更新 |
| E (Exclusive) | 唯一副本，未修改 | 可以 | Host 或其他 agent 无副本，设备可安全升级到 M |
| S (Shared) | 共享副本，未修改 | 否 | Host 或其他 agent 可能也有副本 |
| I (Invalid) | 无有效副本 | 否 | 需从 Host 获取 |
这里面有一个重要的点：E 和 S 的区别。很多工程师容易把 E 当成“独占只读”，其实 E 状态下设备有权利把数据修改为 M，不需要额外通知 Host 去无效化其他副本。我在早期一个项目里，就因为搞混了 E 和 S 状态转换条件，导致 Host 侧的 snoop filter 误判了共享域，触发了一致性错误。那是个非常隐蔽的 bug，抓了将近两周才定位到。
2.4 Snoop 机制与 Back Invalidation
Host 如何知道设备缓存了什么？这就要靠 snoop filter（监听过滤）或者 directory（目录协议）了。CXL.cache 协议没有强制用哪一种，但 Host 必须提供一个机制去跟踪设备缓存状态。
- 当 Host 核心要访问设备缓存的数据时，Host 会发出一条
SnpData或SnpInv请求给设备。 - 设备收到后，根据自身状态返回数据（如果是 M）或执行无效化（如果是 S）。
其中有一个非常重要的消息类型叫 Back Invalidation。Host 可以主动要求设备把某个缓存行变成 I 状态，即使设备觉得自己拥有该行的所有权。我曾经给一个客户做调试，他们的设备在收到 Back Invalidation 后没有正确释放状态，导致 Host 侧误以为设备还持有数据，后续的 DMA 写直接覆盖了内存——结果你懂的，数据全乱了。
避坑指南：Back Invalidation 处理必须是非阻塞的、原子性的。我曾经见过一个实现，在 Back Invalidation 处理流程中插入了 DMA 等待，结果造成死锁。记住：收到 Back Inv 时，设备只有两个动作——返回数据（如果是 M）并转为 I，或直接返回 Ack（如果是 I/S）。不要做额外判断。
2.5 两个关键机制：NoFatal 与强制有序
CXL.cache 还引入了 NoFatal 响应类型。什么意思？就是设备可以不严格遵循 MESI 顺序返回响应。举个例子：设备发出一个 ReqData 请求，Host 返回数据后，设备又发了一个 ReqInv 请求。正常情况下，ReqData 和 ReqInv 不能乱序。但如果启用 NoFatal，设备可以告诉 Host：我这条请求失败了，不会造成致命错误。这就是某些调试时的容错机制。
要注意，NoFatal 只针对特定请求类型，不是所有请求都可以这么玩。当年我们在开发 CXL 桥片时，因为错误地给 SnpData 也加了 NoFatal 标记，结果 Host 端以为数据投递成功了，实际设备被跳过了，第二天调试会就被架构师点名了。
还有一个必须强调的：强制有序（Mandatory Ordering）。CXL.cache 要求所有针对同一缓存线的请求必须按发出顺序完成。设备不能因为想省带宽就把多个请求合并成乱序处理。这个在硬件设计上通常靠一个 per-cacheline 的 FIFO 来实现。
2.6 完整流程图：一次典型的设备缓存访问
下面我用一张 SVG 流程图总结一下从设备发起缓存读请求到收到响应的一致性路径。你可以保存下来作为参考。
注意流程图里第三步的虚线部分。实际中如果其他 agent（比如另一个 CPU 核心）也持有同一缓存行，Host 才会发出 snoop。如果只有设备在请求，Host 可以直接从本地内存返回数据，跳过 snoop 环节。这个判断完全取决于 snoop filter 的实现效率。
2.7 小结一下我们要记住的
- CXL.cache 不是简单的 DMA，它有一套完整的 MESI 状态机处理一致性。
- 两个模型（Host-managed 和 Device-managed）各有适用场景。
- Back Invalidation 是高频调试点，处理不当容易引发数据不一致。
- 强制有序和 NoFatal 两个机制虽然设计巧妙，但滥用会引入微妙的时序问题。
曾踩过的坑：在验证 CXL.cache 一致性时，很多团队只看功能正确性，漏掉了状态机退出和边界情况。我见过三次因为“Snoop 返回和 Request 返回互相等待”导致协议死锁的案例。建议调试时专门构造一个测试用例：让设备不断切换 E、M、S、I，同时 Host 侧频繁发 Back Invalidation，然后检查系统是否还能正确解体。
好了，今天的内容就到这里。理解了这个模型结构，后面我们聊具体的调试工具时，你就能知道每条 message 是在做 MESI 的哪一步了。