📚 课程目录第3章 CXL一致性模型

3. CXL一致性模型

好，咱们进入正题。缓存一致性，这个词你肯定听过。但在CXL的世界里，它和我们传统CPU socket内的Cache Coherency，其实是两码事。说白了，传统的协议是给“一家人”用的，而CXL要管的是“邻居家”甚至“街对面”的缓存。

我记得刚开始研究CXL时，第一个困惑就是：为什么还需要一套新东西？ 直接在PCIe上跑MESI不行吗？嗯，等你真正深入下去就会发现，PCIe的延迟和拓扑，根本扛不住经典的嗅探式一致性。

3.1 为什么需要一套新的一致性模型

先做个思想实验。你在服务器里插了一块CXL内存扩展卡。CPU Core 0写了一个变量，这个变量现在“脏”在Core 0的L1 Cache里。过了一会，CXL内存扩展卡上的控制器想要读这个变量。

传统PCIE：驱动发个DMA读命令，读到的是DDR4/5里的旧值。完蛋。
经典MESI：需要CPU的总线嗅探机制，跨过PCIe桥去通知远端设备。这个路径太长了。

CXL为了解决这个问题，定义了CXL.cache和CXL.mem两套协议。它们不是重新发明轮子，而是把MESI的核心状态机，映射到了一套更适合“设备-主机”异步通信的协议上。

我个人习惯把CXL的一致性模型理解为：一套带有QoS回放的监听过滤协议。你想想看，如果没有监听过滤，一个CXL设备每做一次缓存操作，都要打断主机CPU的所有核心，那性能就崩了。

3.2 MESI协议其实很简单

聊映射之前，咱们快速回顾一下教科书里的MESI。我怕有些同学忘记了。

MESI定义了四种状态：

M (Modified)：只有我有，且数据是脏的。内存中的副本过时了。
E (Exclusive)：只有我有，但数据是干净的。内存副本是最新的。
S (Shared)：不止我有，大家都有。内存副本是最新的。
I (Invalid)：数据无效，我得去别处拿。

这四种状态通过本地读/写和远端读/写请求来转换。我在实际项目中见过有人把M直接改成I，结果总线直接疯了。因为系统默认你必须先把数据写回（Writeback）才能进I。

状态	本地持有	数据清洁	内存有效
M	独占	脏	无效
E	独占	干净	有效
S	共享	干净	有效
I	无	-	无效或无关

避坑指南： 我当年做多核处理器验证时，把E状态理解成了“谁想读都可以”。错了！E状态意味着共享总线上的其他CPU不能有副本。当另一个CPU来读时，E必须降级为S，或者通过总线事务响应。这一点在CXL里同样关键。

3.3 CXL如何映射MESI：核心状态与动作

CXL并没有直接复制MESI这四个字母，而是定义了自己的状态编码。为什么？因为CXL链路不是共享总线，而是点对点链路。你无法通过“拉高一条共享线”来广播。

CXL把一致性状态封装在“回放”（Snoop response）和“回填”（Data response）里。我总结了一套常用的映射关系，你在做CXL设备验证时会不断碰到它。

CXL缓存状态	对应MESI	说明
M (Modified)	M	设备独有，脏数据。写回前不能释放。
E (Exclusive)	E	设备独有，干净数据。可以直接转M。
S (Shared)	S	设备共享，干净。但可能多个设备共存。
I (Invalid)	I	数据不在缓存中，或者被强制无效了。
SF (Snoop Filter)	无直接对应	CXL特有的监听过滤状态。主机知道设备有缓存，但具体是M/E/S不确定。需要发监听请求确认。

你看，CXL多了一个SF (Snoop Filtered) 状态。这个东西在MESI里是没有的。它代表一种“我可能持有该缓存行，但我不确定”的状态。这在CXL的大规模一致性域里非常有用。主机不需要每次都冒失地发送Invalidate请求。

注意： 在CXL 2.0及以后版本中，Host BiDir和Device BiDir握手是核心。如果你的设备发了一个Host Snoop Response说状态是“M-HitM”，但实际数据没有写回，那后果就是数据损坏。这种bug在硬件层面很难追，因为log可能显示状态机正确，但数据路径延迟导致时序错位。

3.4 从MESI到CXL的映射：一个具体例子

我们来看一个最常见的场景：设备读一个缓存行。

设备发起CXL.cache读请求。这个请求到达主机的一致性控制器（通常集成在Home Agent里）。
主机查自己的Snoop Filter。看看这个地址是否在其他CPU核或其他CXL设备里置了M。如果没有，直接走主存。
如果命中M，主机发送一个Snoop请求给占着M状态的那个Agent（可能是CPU Core，也可能是另一个CXL设备）。
那个Agent需要把数据写回（Writeback），并把状态从M降为S或I。
主机拿到数据后，根据策略决定给设备什么权限。如果设备后续很可能写，主机可能给E权限；否则给S。

这个过程你说复杂吧，也就几步。但我在一致性测试中见过最离谱的bug是：设备在收到Snoop请求后，还没写完数据就告诉主机“我完成了”。主机直接下了Invalidate命令，结果数据被覆盖了。

CXL协议里专门定义了“Snoop Response”必须携带HitME”这种元数据。Host必须等到数据真正写回到一致性点（一般是内存控制器或主机侧的缓存），才能认为事务完成。这个是我们在验证时必须用随机化事务注入来覆盖的场景。

我的个人经验： 在所有的一致性测试用例里，Host BiDir与Device BiDir的互斥访问是最容易出问题的。一个CXL设备认为自己有M状态，但在它写回之前，主机CPU另外核心的Store指令也写到了同一个地址。这个时候，CXL的协议要求必须做“冲突解决”——通常是回滚（Retry）设备的事务。如果你的设备没有正确实现Retry逻辑，系统直接死锁。

3.5 一个可读的状态转换：MESI到CXL

下面这张图展示了我刚才讲的核心映射关系。你可以把它看作CXL设备视角的一致性状态机简化版。

3.6 关键区别：监听协议 vs 目录协议

为什么CXL不能直接用MESI？因为MESI是总线嗅探协议。总线上的所有Agent都能看到每个事务。CXL是点对点链路，根本看不到。所以CXL用的是基于目录的一致性协议。主机端的Home Agent充当了目录。

这个区别导致了几个重要的验证点：

没有全局总线：MESI里用“共享总线”实现的原子性（比如原子读-改-写），在CXL里必须通过主机代理 (Host Agent) 来做仲裁。
Snoop Filter放大：由于延迟很大，CXL的一致性事务不能像CPU Socket内那样几纳秒完成。Snoop Filter的条目如果太小，设备就会频繁被Invalidate，性能暴跌。我测试过一块原型卡，当时Snoop Filter条目只有64K，结果随机读写性能只有预期的30%。
回滚与重试：MESI里极少出现“事务回滚”。但在CXL里，主机Agent可能说“等一下，我还没查完，你重试”。如果设备不支持无限次重试，就死锁了。

我曾经踩过的坑： 在验证一个SSD的CXL接口时，主机侧发了一个Back-Invalidate（BI）请求，要求设备放弃所有缓存行。我的设备FW当时只实现了单线程清理，结果在一个繁忙的IO场景下，清理速度慢于主机侧的Snoop请求到达速度。主机认为我永远无法完成，直接挂了。最后解决方案是：设备必须支持“批次无效”，并且在协议层面返回一个“Back-Invalidate Completion”带一个“Partial”状态码，告诉主机我还没扫完，但还在继续。这块逻辑在CXL规范里写得比较隐晦，很多团队都忽略了。

3.7 一致性测试中的常见陷阱

M状态写回丢失：设备标记了M，但在写回过程中，数据总线出错，或者设备主动丢弃了写回请求。协议要求必须保证写回是幂等的，或者至少通过重放机制保证数据到达。
E状态下的非法写：我见过设备在E状态下直接写内存，但没通知主机。结果主机其他核心的缓存还是E，以为自己是唯一的。这种bug一旦出现，数据不一致非常难重现。
S状态下的脏数据回扫：设备持有S状态，但误以为自己有唯一写权限，直接在本地改了缓存。CXL协议允许S状态的设备读，但不允许本地写。你写了，就必须发Host Snoop请求去获取M权限。如果直接写，就是协议违规。
SF状态下的死锁：设备对Snoop Filter的请求没正确响应。主机发一个Snoop请求，设备回复了HitS，但实际数据是脏的。这种不一致一旦发生，直接导致整个一致性域崩溃，只能Reset。

好了，关于MESI和CXL的映射，我就讲这么多。你记住一个核心：CXL的缓存状态虽然名字和MESI一样，但行为逻辑是基于异步请求和目录的。 不能直接套用CPU Socket内的经验。

接下来你会看到一张表格，把刚才说的核心逻辑总结一下。

概念	传统MESI	CXL实现
通信介质	共享总线	点对点链路
一致性点	所有Agent	主机Home Agent
监听方式	广播嗅探	基于Snoop Filter的单播/组播
事务类型	原子操作	非原子的Split Transaction（带Tag）
状态总数	4种	4种标准+SF（Snoop Filtered）
重试	很少见	常见，设备必须支持
延迟容忍	纳秒级	微秒到毫秒级

记住，一致性模型是CXL的魂。你理解了MESI到CXL的映射，后面做测试用例设计的时候，才知道那些随机注入的Snoop请求是什么意思，也才能看懂Trace里这种tag。别急，后面还有实战章节带大家一起撸代码。