CXL.cache H2D Message 释义

---

点击查看精选 CXL 系列文章
点击进入【芯片设计验证】社区，查看更多精彩内容

---

 声明：

• 作者主页：【MangoPapa的CSDN主页】。
• ⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/132647087】。
• ⚠️ 本文目的为 个人学习记录 及 知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
• ⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
• 欢迎大家指出文章错误，欢迎同行与我交流 ~
• 邮箱：[email protected]
• 直达博主：loveic_lovelife 。（搜索或点击扫码）

---

---

---

0. 前言

  为了实现 Host 和 Device 之间的缓存一致性，CXL.cache 提供了 D2H、H2D 两个方向的 Cache 管理，每个方向均有 3 个 Channel：Req、Rsp 及 Data。每个 Channel 由细分为多种 Message，如下图所示。本文对 H2D 方向各 Message 的含义进行解释。

---

1. Req

  H2D Req 用以保证 Device Cache 跟 Host Cache/Memory 的一致性。

  Host CPU LLC Controller 内的 Local Snoop Filter 通过 H2D Req Channel 对 Device Cache 进行 Snoop。H2D Snoop 的目标为 Device Cache 内缓存的归属于 Host Memory 的 Cacheline 数据及状态。对于 HDM-D，该 Snoop 不区分 HDM-D 的 Bias Mode，Device Cache 内属于 Host Memory 的 Cacheline 都会被 Snoop。

  Snoop 请求有 3 种：

• SnpData ，当 Host 想要将归属于 Host Memory 的某条 Cacheline 置为 Shared 或 Exclusive 状态时，其向包括 Device Cache 在内的所有 Peer Cache 发送 SnpData 请求。该请求通常由 Host 端的读请求触发，BE 全为 1。只有所有 Peer Cache 均回复了 RspI*类型的 Rsp 时 Host 才能独享该 Cacheline，否则只能 Shared。Device 收到该 SnpData 请求后，一方面可以将 Device Cache 内该 Cacheline Invalidate 掉，另一方面可以降级为 Share。如果 Device Cache 内该 Cacheline 有脏数据，需要回复 Rsp*Fwd*把脏数据写回到 Host。
• SnpInv ，当 Host 想要将归属于 Host Memory 的某条 Cacheline 独享时，其向包括 Device Cache 在内的所有 Peer Cache 发送 SnpInv 请求来 Invalidate 所有其他 Peer Cache 内的该 Cacheline。该请求通常由 Host 端的写请求触发，BE 全为 1。该请求对于的 D2H Rsp 只能是 RspI*。如果 Device Cache 内该 Cacheline 有脏数据，需要回复 RspIFwdM 把脏数据写回到 Host。
• SnpCur ，仅获取 Cacheline 最新数据，不改变 Cacheline 状态。该请求相对比 SnpData 柔和了很多，如果 Device Cache 内该 Cacheline 有脏数据，需要回复 RspIFwdM 把脏数据写回到 Host，但仍能保持 Modified 状态，Host Cache 该 Cacheline 状态不变也不会去争夺 Exclusive 权限。

  H2D Req 发出之后，如果 Host 收到了 Rsp*Hit*类型的 D2H Rsp，表明当前请求已经完成；如果收到 Rsp*Fwd*类型的 D2H Rsp，表面 Device 有数据需要写回到 Host，Device 会通过 D2H Data Channel 把数据写回。

---

2. Rsp

  H2D Rsp 是一条 Message 或多条 Message 的组合，用以响应 D2H 方向的 Cache 请求，有两大作用：① 指示 Host 一致性的完成情况及 Device Cacheline 可进入的状态；②请求 Device 反馈数据。

  H2D Rsp 共 7 种：

• WritePull ，Host 告知 Device 进行写数据，但无需更改 Cacheline 状态。只有 WrInv 的时候会用到 WritePull，WrInv 的时候需要先反馈 WritePull 再反馈 GO（I/Err）。
• GO ，Global Observation，相当于 Ack 的作用，指示 Device 中该 Cacheline 可用的状态，GO 包括 GO-M/E/S/I/Err。对于 GO-M，Device Cache 不能 Drop 该 Cacheline 且后续必须该 Cacheline 写回；对于 GO-I/Err，Device 收到后不能缓存该 Cacheline。
• GO_WritePull ，GO+WritePull 的组合，Device 收到该 Rsp 后写数据到 Host，用于 Post Write。
• GO_WritePull_Drop ，与 GO_WritePull 类似，但无需写数据到 Host，目前仅能用于 CleanEvict 请求的情况下。对于需要部分写的情况（BE 非全 1，比如*WrInv*），Host 不能反馈 GO_WritePull_Drop，这个 Data 不能 Drop 掉。
• GO_ERR_WritePull ，与 GO_WritePull 类似，但是请求出现了错误
• Fast_GO_WritePull ，与 GO_WritePull 类似，但只能作为 WOWrInv/F 等弱内存顺序的写请求。常规情况下（非弱内存顺序），Host 需要完成 Device Cache、Host Cache 及所有 Peer Cache 的全局缓存一致性操作后才能反馈 GO_WritePull；在若内存顺序时，Host 只完成局部缓存一致性即可反馈 Fast_GO_WritePull 要求 Device 写数据过来，响应更快。举个例子：CPU Socket0 的 LLC0 下挂有多个 CXL.cache 设备 D0 & D1，CPU Socket1 的 LLC1 下挂有 CXL.cache 设备 D2 & D3，两个 CPU Socket 通过一致性对称链路连接在一起。D0 向 LLC0 发起 Cache 写请求，LLC0 跟 D0、D1 Cache 完成一致性操作后，不等待跟 LLC1、D2、D3 完成一致性就立刻反馈 Fast_GO_WritePull 给 D0，D0 写数据到 Host。待全局一致性操作完成后进一步给 D0 反馈 ExtCmp。
• ExtCmp ，跟 Fast_GO_WritePull 一样只能作为 WOWrInv/F 等弱内存顺序的写请求这里的"Ext"个人理解是 Extend 的意思。Fast_GO_WritePull 是局部一致性完成之后发出的第一次响应，ExtCmp 是在全局一致性完成之后在 Fast_GO_WritePull 基础上进一步扩展的 Completion。只有全局一致性完成操作完成之后，Memory 里的数据才敢保证是最新的。

  以上 H2D Rsp 中，CQID 字段采用 D2H 的 CQID。若该 H2D Rsp 需要 D2H 后续反馈数据（*WritePull*类型的 H2D Rsp），该 H2D Rsp 的 RspData 填充 12b 的 UQID，供 D2H Data 的 UQID 字段取用。对于 GO，RspData 字段用以指示当前的 GO 类型：M/E/S/I/Err。

  在以上解释上做点补充：

• *WritePull*（不含 Drop）是 Host 发给 Device 的指示信号，指示 Device 可以开始往 Host 写数据了，Device 收到*WritePull*之后通过 Data Channel 往 Host 写数据。
• 对于 D2H 的写请求，Host 反馈给 Device 的 GO 只能是 GO-I/Err。GO 可以在 WritePull 之后到，也可在同一 Flit 中同时到，但不能早到。
• 对于 Posted Write，Host 只反馈 GO-I/WritePull 的组合 GO_WritePull 即可。对 Device 而言 Device 收到 GO_WritePull 发出写数据之后即可认为该笔写操作完成，对 Host 而言 Host 收到 Device 发的数据即可认为写操作完成。
• 对于 NP Write，对 Device 而言，强内存顺序时 Device 收到 GO-I、弱内存顺序时候收到 ExtCmp 才算完成。

---

3. Data

  回应 D2H 所请求的数据。

---

4. Q&A

1. 为什么 H2D 方向没有读写请求？
   请问读写什么？CXL.cache 存在的意义是便于 Device 去拿 Host Memory 的数据，是以 D2H 方向的读写访问为主的。Device 取回 Host Memory 数据后放在 Device Cache，Host 只负责来嗅探这些 Cacheline 就好了，没有必要去读这些本属于 Host Memory 的 Cacheline。当然 Host 有必要能够直接取到 Device Memory 的数据，但拿就是 CXL.mem 的故事了，可以通过 M2S Req/RwD 来访问。

2. 如果 Device Cache 内某归属于 Host Memory 的 Cacheline 为独享状态， Host 还能对其进行 Snoop 吗？
   能。只要是 Device Cache 内归属于 Host Memory 的 Cacheline，Host Snoop Filter 内该 Cacheline 都处于 Active 状态，Host 都可以进行 Snoop。

---

5. 参考

1. CXL Base Spec, r3.0
2. Cache 一致性的那些事儿 (2)–Snoop 方案 - 知乎 (zhihu.com)

---

— END —

---

精选往期 CXL 协议系列文章，请查看【 CXL 专栏】

⬆️ 返回顶部 ⬆️