4. CXL.cache 的设备角色：Host 端与 Device 端的对称与非对称模型
各位好，今天我们来聊 CXL.cache 里一个绕不开的话题——Host 和 Device 到底是不是「对等」的？
刚接触 CXL 的时候，我一度以为这两边就像网络协议里的 peer，你发一个 snoop 我也能发一个 snoop。后来调协议栈的时候被硬生生打脸了……其实 CXL.cache 的模型是非对称的，而且这个非对称是刻意设计的。
但话说回来，非对称不代表 Device 端就是「二等公民」。咱们把它掰开揉碎看看。
4.1 Host 与 Device：谁主谁从？
CXL.cache 规范严格定义了两个角色：
- Host：一致性域的管理者，拥有内存系统的最终控制权。
- Device：一致性域的参与者，通过 CXL.cache 协议访问 Host 内存并缓存数据。
打个比方，Host 是图书馆管理员，Device 是读者。读者可以借书（读请求）、还书（写回），书在读者手里时可以自己看，但管理员要查谁借了什么书（目录管理），必要时还能强制读者交回书（监听回写）。
关键点：CXL.cache 协议中 只有 Host 端发送监听请求（Snoop），Device 端从未主动发起监听。这是非对称最直观的体现。
4.2 对称模型 vs 非对称模型
我早期参与一个学术项目时，团队想当然地给 Device 也画了监听发送器，结果仿真直接死锁。为什么？因为 CXL.cache 的架构压根不允许对称干预。
| 维度 | 对称模型（理论上） | CXL.cache 非对称模型（实际） |
|---|---|---|
| 角色平等性 | 双方都可做管理方 | Host 唯一管理方，Device 仅请求方 |
| 监听方向 | 双向监听 | 仅 Host→Device 单向外发监听 |
| 缓存状态管理 | 双方独立维护目录 | Host 维护全局目录，Device 仅维护本地 Tag |
| 内存归属 | 双方均可拥有物理内存 | Host 内存为主，Device 本地内存一般走 CXL.mem 而非 CXL.cache |
| 死锁风险 | 高，需复杂协议处理 | 低，协议本身就避免了循环依赖 |
说白了，CXL.cache 的非对称模型是工业界的务实选择。你想想看，如果允许 Device 也能往 Host 发监听，就要为双方都实现完整的监听过滤、重排序、死锁避免逻辑——芯片面积和验证工作量直接翻倍。当年做类似协议的时候，光是单调计数器对齐就让我熬了三个通宵。
4.3 为什么非对称反而更好？
我曾经跟一个刚入行的同事解释这个设计：「对称模型看起来公平，但实际跑起来两边都在猜对方的状态，性能不见得好。」
- 一致性协议简化：Host 作为权威（Authority），所有缓存行的所有权切换必须经过 Host。Probe/Listen 的发送窗口完全由 Host 控制，没有冲突和竞争。
- 死锁本质规避：协议层不依赖信用或重试来避免循环，因为只有一个 snoop 发起方。
- 硬件实现友好：Device 侧只需要一个简单的 CXL.cache 请求机（Request Agent），不需要实现完整的 snoop 过滤器。
个人经验：在 FPGA 原型验证阶段，我们让 Device 端只处理来自 Host 的 CXL.cache 请求（Read、Write、RWIM、Probe 响应等），实现量比 Host 端大概少了 40%。但要注意——Device 端的 tag 控制器必须足够快，否则 Host 侧 probe 超时会导致一致性错误。
4.4 非对称模型下的通信拆解
咱们用一张图把消息流画清楚。下面是典型的 CXL.cache 交互：
这张图的信息量其实不小。你仔细看：①和②是一对请求-完成，这是正常的内存事务；而③和④是监听事务，完全是 Host 主导的。Device 在协议层没有「反问」的能力。
4.5 实战避坑：别把对称习惯带进来
之前有个团队从 CCIX 转过来做 CXL，他们在 Device 侧实现了完整的监听过滤逻辑，结果发现 Host 压根不会接收——因为 CXL.cache 协议不允许 Device 向 Host 发送 Probe 类型消息。浪费了几个月的设计。
重要提醒：
- Device 端 必须 实现 Probe 响应通道（Host 监听请求 -> Device 必须及时响应）。
- Device 端 不得 发送任何 Probe 类型的 request 消息（协议类型表中没有该项）。
- Host 端的 Probe 超时定时器要设计合理——我曾经碰到过 Device 响应因为内部缓冲排队而延迟，Host 过早重试导致数据乱序。
嗯，这里还有一个细节：非对称模型下的「有序性」反而是比较好保证的。因为所有 Probe 从 Host 发出，Host 能够控制 probe 与内存访问之间的顺序。在实现 Host 侧 probe 调度器时，我习惯把 pending 的写请求和 probe 放在同一个优先级队列里，避免先 probe 后写导致的 stale read 问题。
建议：如果在 Host 侧做 CXL.cache 的目录实现，可以把 M 状态（Modified）和 E 状态（Exclusive）的 probe 处理分开——M 需要写回，E 只需 invalidate。我第一版写成一个函数入口，结果状态机复杂度飙升，后来拆开反而清晰了。
4.6 小结：对称与非对称的边界
事实上，CXL 协议族里也有对称的地方——比如 CXL.mem 在两个 CXL 设备之间可以通过背靠背（Back-to-Back）方式实现对称内存语义，但那已经不是 CXL.cache 的范畴了。CXL.cache 从一开始就为了低延迟、高确定性选择了非对称模型。
你问我为什么不能把 Device 做得跟 Host 一样？成本、验证、性能，三者都不允许。工业界不做学术式的对称公平，只做可落地的权衡。我后来在给客户做培训时经常说：「非对称不是歧视，是共识。」