CXL.cache协议详解：请求类型、状态机与一致性流程
在上一章我们聊了延迟感知的背景，这一章咱们就扎进CXL.cache协议的核心细节里。说实话，刚接触CXL规范时，那几百页的协议文档看得我头皮发麻。但干久了你会发现，核心就三块东西：请求类型、状态机和一致性流程。搞懂了这三样，你基本就能读懂CXL.cache的底层对话了。
3.1 请求类型：设备跟主机怎么“说话”
CXL.cache是设备主动发起缓存的协议。设备（比如加速器、智能网卡）可以把自己热数据放在本地缓存里，然后通过CXL.cache请求跟主机保持一致。我个人习惯把请求分为两大类：监听请求和写请求。
核心要点：CXL.cache设备不是被动等主机来问，而是主动告诉主机“我这有份数据，你帮我看着点”。
3.1.1 监听请求（Snoop 类）
这类请求是主机发给设备的。说白了就是主机想知道：“你缓存里有没有这条数据？有的话赶紧给我看看。”我记得早期在做原型验证时，总以为Snoop请求只是查询，实际上它还能触发状态迁移。
| 请求类型 | 方向 | 用途 |
|---|---|---|
| SnpData | 主机 → 设备 | 请求缓存行数据，设备若有则返回 |
| SnpInv | 主机 → 设备 | 无效化设备的某条缓存行 |
| SnpRd | 主机 → 设备 | 仅查询状态，不要求数据回传 |
项目经验：我曾经在一个SoC原型里发现SnpInv处理不当，导致设备反复回写脏数据。后来查了查，原来是状态机里漏了“等待写回”的中间态。避坑指南：实现SnpInv时，一定要预留处理Pending写回的时间窗口。
3.1.2 写请求（Cache 类）
设备本地改了数据，想写回给主机，就用这类请求。核心是WrWb（Writeback）和WrWbData。前者只传地址，后者连数据一块发。
注意：WrWbData不一定每次都发完整64字节。如果你的设备是窄带缓存（比如只改了几个字），建议先合并再写回，否则总线利用率会很难看。
3.2 状态机：设备缓存行的“生老病死”
CXL.cache设备内部的状态机，我习惯拿标准的MESI做参考，但CXL做了点变通。你想想看，设备缓存只是主内存的一个子集，所以状态转换跟CPU缓存很像，但多了些因CXL特性带来的特殊路径。
// 简化版状态转换规则（以SnpInv触发为例）
Current State = Modified
→ 收到 SnpInv：需要写回数据到主机，之后状态变 Invalid
→ 若写回未完成，状态保持 Modified（Pending Writeback）
Current State = Shared
→ 收到 SnpInv：直接变为 Invalid（因为没修改过）
→ 收到 SnpData：数据返回主机，保持 Shared 或变 Invalid
Current State = Invalid
→ 设备本地 Miss，从主机读数据 → 状态变为 Shared 或 Exclusive
为什么会有Pending Writeback？因为CXL.cache是点对点协议，设备写回主机需要总线事务。如果写回还没完成就收到新的监听，必须先把脏数据冲出去，否则一致性就崩了。
| 状态 | 含义 | 常见触发场景 |
|---|---|---|
| M（Modified） | 设备独占且已修改 | 设备本地写缓存命中 |
| S（Shared） | 多设备共享，未修改 | 主机或其他设备也持有 |
| I（Invalid） | 无效，需要重新加载 | 收到SnpInv或写回完成 |
| E/F（Exclusive/Forward） | 独占但未修改 | 第一次从主机加载 |
一点经验：E/F状态在CXL.cache里其实有点微妙。我遇到过设备想把缓存行当E，但主机那边已经把它标成S了。后来用SnpRd先“探一下”再加载，就能规避这种不一致。
3.3 一致性流程：三步走完一次完整交互
前面两节讲的是“零件”，现在咱们拼起来看一个完整的一致性流程。拿最常见的场景举例：设备想读一条它没有的数据，而且不想把所有权给出去。
- 步骤一：设备发起RdCurr（读当前值）
- 设备检查本地缓存，状态为Invalid
- 通过CXL.cache发送RdCurr请求，带上目标地址
- 步骤二：主机Snoop其他Cache
- 主机收到请求，检查自身及其他设备缓存
- 如果有Modified副本，触发写回；如果有Shared副本，不发回数据只改状态
- 步骤三：数据返回+状态更新
- 主机把最新数据通过CXL.mem或CXL.io返回给设备
- 设备将缓存行状态设为Shared（假设有其他共享者）
嗯，这里要注意一点：CXL.cache请求的响应不是立即的。协议允许主机插入一个Go（授权）事务，用来告诉设备“你的请求我收到了，等着”。设备在等Go的时候别傻等，可以干点别的请求（前提是不同地址）。
流程图：CXL.cache完整性交互示例
踩坑记录：我曾经在一个项目中忽略了“Go”事务的超时处理。设备发出了RdCurr，主机回了个Go，然后就卡住了（因为有其他高优先级事务）。设备等了1ms没等到数据，直接就超时重置了状态机，结果数据回来时状态已经是Invalid，导致丢数据。教训：Go之后一定要设一个合理的等待计数器，或者用Nack让设备重试，别死等。
3.4 小结：记住这三个“锚点”
CXL.cache虽然协议栈长，但你在实现时只需要死磕三件事：
- 请求类型：搞清楚什么时候用Snoop什么时候用Cache写，别把方向搞反——主机和设备的角色不能乱。
- 状态机：画一张MESI + Pending的转换图，贴在工位上。调试时90%的bug都可以用状态机推理出来。
- 一致性流程：理解“请求→授权→数据”这个三段式。任何中断、超时、乱序都会破坏它。
个人习惯：我每次开始新项目，都会先在验证环境里把这三个锚点的错误注入跑一遍。比如故意让设备在Modified状态下不写回，看看协议层能不能挡回来。这比后期抓bug省心多了。