CXL.cache H2D/D2H 请求响应对应关系

关系"/>

CXL.cache H2D/D2H 请求响应对应关系

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

📢 声明：

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

文章目录

• 1. D2H Req – H2D Rsp
• • 1.1 Host Memory 区域
  • 1.2 Device Memory 区域
• 2. H2D Req – D2H Rsp

1. D2H Req – H2D Rsp

  对于 D2H 方向，不同类型的设备访问不同 Memory 区域时支持的 CXL.cache 请求及 D2H Req 跟 H2D 的映射关系有所不同。

  Device 是如何知道所请求的地址是 Host 还是 Device Memory 区域？——首先，Device 知道自己是哪种类型；其次，有 Bias Table。Type 1 只能访问 Host Memory 区域，Type 3 不支持 CXL.cache，Type 2 HDM 有 Bias Table 来指明地址区域所属的 Bias 类型，在这张表里的就是 Device Memory 区域。

1.1 Host Memory 区域

  如果访问的为 Host Memory 区域，D2H Req 跟 H2D Rsp 的 Mapping 关系如下表所示。

  请求不是随便发的，需要根据 Device Cacheline 当前状态来发，是有前提条件的。Cacheline 不同状态下允许发送的请求如上表右半部。

1.2 Device Memory 区域

  如果访问的为 Device Memory 区域，D2H Req 跟 H2D Rsp 的 Mapping 跟 HDM 的类型有关：

• 对于 HDM-H 区域，其仅用于 Type 3 类型的 Device，不支持 CXL.cahce 操作。
• 对于 HDM-D Device Bias 区域，Host Cache 内没有其备份，Device 不应（Not Expected）向 Host 发送该地址的 CXL.cache 相关请求，相关请求全部在 Device 内部完成。不期望发，但就是发了怎么办？——Spec 里没说，大概率是 Host 回复 GO-Err。
• 对于 HDM-D Host Bias 区域，不同请求有所不同：
  • 对于 WrCur、ItoMWr、WrInv、CacheFlushed，可以发往 Host，其流程跟访问 Host-attached Memory 相同；
  • 对于 CleanEvict、DirtyEvict 及 CleanEvictNoData 等带有驱逐 Device Cacheline 的请求，不应发往 Host，无论哪种 Bias Mode 均在 Device 内部完成；

  猜测的内部处理方式：对于 E 或 S 状态的 Cacheline，数据是干净的，直接把该 Device Cacheline Invalidate 掉就好了；对于 M 状态的 Cacheline，该 Cacheline 为 Device 独享，Peer Cache 中不存在该 Cacheline，Device 内部直接把脏数据写回到 Device Memory 即可，不必通知 Peer Cache。

• 对于其他请求，可以发往 Host，Host 通过 CXL.mem 把相关地址访问请求 Forward 回 Device。
• 如果 Host Cache 内 Cache Hit 也要 Fwd 回来吗？为什么？(待阐释)
• 为什么 CLFlush Fwd 回来是 MemRdFwd? (待阐释)
• 对于 HDM-DB 区域，支持的 CXL.cache 请求有：ItoMWr、WrCur、WrInv 及 CacheFlushed，其他的不支持，采用 CXL.mem 的 Back Invalidation 来实现相同功能。

2. H2D Req – D2H Rsp

  H2D 方向的请求为 Snoop 请求，只能是 Host Memory 区域。H2D Req 跟 D2H Rsp 的 Mapping 关系如下表所示。

  总结如下：

• 对于任意 H2D 的 Snoop 请求，若 Device Cache 内不存在该 Cacheline，则 Device 直接回复 RspIHitI。
• 对于 SnpData，如果 Device Cache 内存在该 Cacheline 且数据 Clean（为 S/E 状态），Host 只要求共享并不独占，Device 回复 RspSHitSE；如果数据 Dirty（为 M 状态），Device 将脏数据写回后可以 Invalidate 该 Cachline 也可以仍然保留该 Cacheline 并很 Host 共享。
• 对于 SnpInv，如果 Device Cache 内存在该 Cacheline，不管其状态如何都必须将其 Invalidate 掉，有脏数据要写回。
• 对于 SnpCur，如果 Device Cache 内存在该 Cacheline，Device 可以像回复 SnpData 那样回复 SnpCur；考虑到 Host 并不关心 Device 内该 Cacheline 的状态，Device 也可以回复 RspV*不指明状态（这里的 V 可以认为是 Valid，有效）。如果 Device 需要写回脏数据，则通过 Rsp*Fwd*来告知 Host。

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

⬆️ 返回顶部 ⬆️