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

news2025/1/20 18:25:58

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

📢 声明：

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

— END —