CXL.cache 架构详解：设备角色与缓存层级
CXL.cache 这块，说白了就是让连在总线上的设备，能直接去摸主机的缓存。听起来简单吧？但实际落地的时候，设备角色怎么分、缓存层级怎么搭，坑特别多。我最早接触这玩意时，光理解设备到底是主人还是仆人，就纠结了好几天。
嗯，我们先来看两个核心概念：设备角色 和 缓存层级。把它们搞明白，后面调试症状才能对号入座。
设备角色：谁是主子？
在 CXL.cache 的体系里，设备就两种身份——Host 和 Device。你想想看，这跟咱们平时说的主从关系有点像，但又不完全一样。
- Host：就是 CPU 那一边，内存的最终主人。它负责维护整个系统的缓存一致性。
- Device：一般是加速器、智能网卡之类的。它带着自己的缓存，想通过 CXL.cache 协议去共享 Host 的内存。
我记得有一次项目，同事设计了一款 AI 加速卡，它的片上 SRAM 想通过 CXL.cache 直接访问主机内存。结果调试的时候发现，它总拿不到最新的数据。折腾了好久才发现，设备端把自己角色配成了 Host——这不就成了两个主人打架吗？
| 角色 | 谁在扮演 | 核心职责 |
|---|---|---|
| Host | CPU、内存控制器 | 管理一致性域，处理 snoop 请求，提供 MESI 状态 |
| Device | 加速器、NVMe、智能网卡 | 缓存主机数据副本，通过 CXL.cache 协议发送读/写请求 |
缓存层级：H0、H1、H2 的区别
CXL.cache 缓存层级分三级——H0、H1、H2。乍一看像是 CPU 的 L1/L2/L3，但其实完全是另一回事。说白了，它们是设备端对“数据在哪里”的描述，而不是物理缓存深度。
- H0 (No Cache)：设备不带任何缓存。请求直通 Host。这跟裸的 PCIe 没啥区别。
- H1 (Cache with Victim)：设备有自己的小缓存。当它替换掉一行数据时，会把被踢出去的旧数据（victim）回写或无效化给 Host。
- H2 (Cache without Victim)：设备也有缓存，但不需要回写 victim。替换时直接把旧数据丢掉就行。Host 必须保证那些数据在其他地方有副本。
这里有个容易懵的点：H2 并不是比 H1 更强，而是场景不同。H1 适合设备需要长期持有数据、写回不频繁的场景；H2 适合数据本身就是临时读一读，丢了也无所谓的场景。我早期做过一个网络卸载引擎，用了 H2 层级，结果发现 CPU 那边数据总被丢掉，不得不改成 H1 配合主动回写。
来，我们看一眼整体架构的关系图：
缓存行状态与一致性协议
CXL.cache 用的是一致性协议，叫 MESI 的变种。设备侧的缓存行状态和 CPU 那边差不多，但注意：设备是看不到 Host 内部 L1/L2 的，它们只通过 CXL.cache 的请求和响应来推断状态。
- M (Modified)：当前设备独占了这行数据，并且改过了。Host 那边不能有这个行。
- E (Exclusive)：独占但没有修改。Host 可能也有副本但也是干净的。
- S (Shared)：多个设备或 Host 共享这个行，都是干净的。
- I (Invalid)：这行在设备缓存里无效。
你想想看，如果设备是 H1 层级，一个 Victim 行原来状态是 M，它回写给 Host 时必须保证 Host 接收后状态变成 E 或 S，否则后续读会读到脏数据。我曾经在调试一个 H1 设备时，碰到过回写时状态没同步，结果 Host 认为那行是 I，自己又去内存里读旧数据——这就是典型的缓存一致性丢失。
H1 vs H2 的设计权衡
| 维度 | H1 | H2 |
|---|---|---|
| 受害者处理 | 必须回写 / 无效化 | 直接丢弃 |
| 一致性负担 | 较高，需要与 Host 交互 | 较低，Host 不需要关心丢掉的缓存 |
| 适用场景 | 设备缓存持久性要求高 | 设备缓存只读或临时性数据 |
| 调试难度 | 较复杂，Victim 路径易错 | 相对简单，但数据丢失风险大 |
我个人建议，如果设备主要做计算加速，缓存数据是中间结果，选 H2 就行，减少回写带来的延迟。如果设备要做数据序言或日志持久化，那就必须用 H1，甚至还得配合 Flush 指令强制写回。嗯，这里要注意，不要因为 H1 看起来功能更强就盲目用它，有时候 H2 更清爽。
一个实际的调试案例
我记得有一次帮朋友调试一个 CXL 交换机的验证环境。仿真里设备端发 H2 读请求，总拿不到正确数据。我抓了协议 trace 一看——设备发出的请求带了 H2 标记，但缓存行状态却是 M。设备根本没写过这行，状态就不该是 M。这就是设备侧缓存状态机没初始化好的问题。改了状态机的初始化逻辑，问题就消失了。
你想想看，如果当时不看 trace，光靠瞎猜，可能永远找不到问题。所以对 CXL.cache 的调试，往往是从状态机入手。