CXL 3.1：CXL.cache 与 CXL.mem

3.2 CXL.cache

3.2.1 概述

CXL.cache 协议把设备与主机之间的交互定义为一系列请求。每个请求至少关联一条响应消息，有时还伴随数据传输。接口在两个方向上各包含三个通道：请求（Request）、响应（Response）和数据（Data）。从设备到主机的方向称为 D2H，从主机到设备的方向称为 H2D。独立通道使不同类型的消息能够使用专用线路，从而实现解耦，并提高每条线路的有效吞吐量。

D2H Request 承载设备发往主机的新请求，这些请求通常以存储器为目标。每个请求会收到零个、一个或两个响应，最多返回一条 64 字节缓存行数据。D2H Request 可以被反压。D2H Response 承载设备发往主机的全部响应，例如设备对侦听请求的响应；响应会说明设备缓存最终保留的行状态，也可能说明数据正被返回到主机指定的数据缓冲区。D2H Data 承载设备发往主机的全部数据与字节使能，数据可能来自隐式写回（侦听的结果），也可能来自显式写回（缓存容量驱逐的结果）。该通道总是传输完整的 64 字节缓存行，并且必须能够取得进展，否则可能发生死锁。

H2D Request 承载主机发往设备的请求，它们主要是用于维持一致性的侦听。侦听可能要求设备返回数据，因此请求中会携带返回数据应写入的缓冲区位置。H2D Request 可以因设备资源不足而受到反压，但这些资源必须能够在不依赖 D2H Request 前进的情况下释放。H2D Response 承载排序消息以及写数据拉取消息，并携带原始设备请求的标识符。H2D Data 则向设备交付读取请求的数据；每次均传输完整的 64 字节缓存行，并且只能因链路层信用不足而暂时阻塞。

图 3-10：CXL.cache 通道

Figure 3-10 CXL.cache Channels

图 3-10：CXL.cache 通道。D2H 与 H2D 两个方向分别具有 Req、Resp 和 Data 三条独立通道。

3.2.2 CXL.cache 通道说明

3.2.2.1 通道排序

通常情况下，所有 CXL.cache 通道都必须彼此独立工作，以保证协议能够持续向前推进。若设备针对地址 X 的请求必须等待该地址的全部侦听响应，而不同通道又相互依赖，就可能形成循环等待并导致死锁。

唯一需要维持跨通道顺序的特殊情况与全局可观察（Global Observation，GO）有关。主机必须等待设备观察到通过 H2D Response 发送的 GO 消息，之后才能针对同一地址发送后续侦听。主机可假定：某一周期内已经通过 CXL.cache 发出的 GO，不会被后续周期发出的侦听越过。若一项事务在同一通道上包含多条具有预期顺序的消息，设备和主机必须通过序列化消息确保观察顺序正确，例如 WrInv 中位于 WritePull 与 GO 之间的 Data 消息。

3.2.2.2 通道信用

为保持接口模块化，发送方不能假定某条通道随时都有链路层信用。因此，每发送一条消息都必须消耗一个信用，并从接收方收集归还的信用。接收方处理完消息、释放缓冲区后归还信用；若没有可用信用，发送方必须等待。信用计数器在达到最大值后饱和即可，并不要求双方逐一核对所有信用。表 3-12 总结了哪些通道必须排空以保证前向进展，以及哪些通道可以无限期阻塞；完整排序规则见规范 3.4 节。

3.2.3 CXL.cache 线级格式

每种 CXL.cache 消息支持三种 Flit 变体：68B Flit、256B Flit 和 PBR Flit。每条链路具体使用哪一种格式，由物理层按照第 6 章的规定协商确定。

3.2.3.1 D2H Request

D2H Request 的字段定义见表 3-13。主要字段包括：表示请求有效性的 Valid、表示操作类型的 Opcode、用于关联响应和数据的 CQID、非时序提示 NT、逻辑 CacheID、以 64 字节缓存行为粒度的物理地址 Address[51:6]，以及 PBR 路由使用的 SPID/DPID。

3.2.3.2 D2H Response

D2H Response 的字段定义见表 3-15。UQID 回显原 H2D Request 中的唯一队列标识，用于指出主机中的目标跟踪项；Opcode 决定响应语义。

3.2.3.3 D2H Data

D2H Data 头字段见表 3-16。ChunkValid 用于 32 字节传输时指明缓存行的上半或下半部分；Bogus 表示驱逐请求发出后，数据已经因侦听而被返回，因而当前数据可能已经过时，主机应丢弃；Poison 表示数据损坏；BEP 表示消息中带有字节使能。68B Flit 与 256B Flit 对字节使能的承载方法不同。

3.2.3.4 H2D Request

H2D Request 的字段定义见表 3-17。Opcode 表示主机发往设备的侦听类型；Address[51:6] 指定目标缓存行；UQID 标识发起请求的主机跟踪项；CacheID 指定消息的逻辑目标缓存。

3.2.3.5 H2D Response

H2D Response 的字段定义见表 3-18。Opcode 决定响应类型，并进一步决定 RspData 是携带 UQID，还是携带 MESI 状态信息。RSP_PRE 提供性能监视信息；CQID 回显 D2H Request 的命令队列标识。缓存状态编码见表 3-20。

3.2.3.6 H2D Data

H2D Data 的字段定义见表 3-21。CQID 指出数据对应的设备请求；ChunkValid 指示 32 字节分块；Poison 表示损坏数据；GO-Err 表示数据来自错误事务，设备不得缓存该数据，也不得用其响应侦听。

3.2.4 CXL.cache 事务说明

3.2.4.1 HDM-D/HDM-DB 的设备附加内存流程

当 CXL Type 2 设备通过 HDM-D 或 HDM-DB 向主机暴露内存时，设备负责解决主机与设备之间的 HDM 一致性。CXL 提供两种协议方案：HDM-D 使用 CXL.cache Request；HDM-DB 使用 CXL.mem Back-Invalidate Snoop（BISnp）。

3.2.4.2 设备到主机的请求

设备到主机事务可归纳为读取（Read）、只取得排序/所有权而不返回数据的 Read0、写入（Write）以及 Read0-Write。设备必须先取得 D2H Request 信用再发送请求。主机使用 H2D Response 返回 GO、WritePull 或组合响应，必要时通过 H2D Data 返回一条完整缓存行。设备只有在收到规定的 GO/完成消息以及全部数据后，才能释放事务跟踪项。

CXL.cache Read

读取请求需要 D2H Request 信用。主机通过 H2D Response 返回 GO，并通过 H2D Data 返回完整缓存行。GO 携带最终缓存状态或一次性使用语义；数据与 GO 可以在不同时间到达，但主机与设备必须遵守侦听和排序限制。

图 3-11：CXL.cache Read 行为

Figure 3-11

图 3-11：设备发送 D2H 读取请求，主机返回 H2D GO 响应和两段 32 字节 H2D Data。

CXL.cache Read0

Read0 需要 D2H Request 信用，但不返回数据。设备收到 GO 后即可认为请求完成并释放跟踪项。CLFlush 等特殊周期属于这一类别。

图 3-12：CXL.cache Read0 行为

Figure 3-12

图 3-12：Read0 只需要 D2H Request 与 H2D GO，不发生数据传输。

CXL.cache Write

写事务需要 GO 和 WritePull。对某些请求，二者可以合并；要求非投递语义时，WritePull 先发送，写操作被全局观察后再发送 GO-I。WritePull 触发设备向主机发送总计 64 字节的数据。设备在收到 GO-I 并完成全部数据发送后认为事务完成；主机在收齐 64 字节并发出 GO-I 后认为写入完成。

图 3-13：CXL.cache 设备到主机写行为

Figure 3-13

3-13：设备发出写请求，主机返回组合 GO/WritePull，设备随后发送两段数据。

图 3-14：CXL.cache WrInv 事务

Figure 3-14

图 3-14：WritePull 与 GO 分离时，数据消息承担二者之间的序列化作用。

图 3-15：带 FastGO/ExtCmp 的 WOWrInv/F

Figure 3-15

图 3-15：弱排序写可以先收到 FastGO 与 WritePull，最终通过 ExtCmp 表示已在系统范围内完成观察。

CXL.cache Read0-Write

Read0-Write 请求在主机收到请求后返回一个合并的 GO-I/WritePull。WritePull 触发设备发送总计 64 字节的数据。设备收到 GO-I 并发完数据后完成事务；主机收齐数据并发送 GO-I 后完成事务。ItoMWr 属于此类。

图 3-16：CXL.cache Read0-Write 语义

Figure 3-16

图 3-16：Read0-Write 通过组合 GO-I/WritePull 请求设备发送写数据。

3.2.4.3 设备到主机的响应

设备对侦听的响应通过 D2H Response 返回。响应编码表示设备最终留下的缓存状态，以及是否通过 D2H Data 返回缓存行。RspFwd 类响应表示设备正返回当前数据；是否携带状态与数据取决于具体 Opcode。表 3-25 给出编码。

3.2.4.4 主机到设备的请求

主机侦听除本地 H2D Request 信用外不需要额外信用。设备始终通过 D2H Response 返回侦听响应；若响应为 RspFwd，还必须通过 D2H Data 向原请求的 UQID 返回 64 字节数据。对无数据的转发情形，响应发出后主机即可认为侦听完成；若带数据，则最后一段数据和响应都发出后才算完成。

图 3-17：CXL.cache 侦听行为

Figure 3-17

图 3-17：主机发送 H2D Snoop，设备返回 D2H 响应；RspIFwdM 等响应还会返回数据。

3.2.4.5 主机到设备的响应

H2D Response 可承载 GO、FastGO、ExtCmp、WritePull 及其组合消息。GO 给出缓存行的下一所有权与缓存状态；WritePull 要求设备发送写数据；ExtCmp 表示请求已经到达系统范围内的完成点。GO_ERR 和 GO_ERR_WritePull 表示事务发生错误；后者仍要求设备发送数据，但主机会丢弃这些数据，设备按 Error 状态处理。

3.2.5 可缓存性细节与请求限制

3.2.5.1 GO-M 响应

主机返回 GO-M 表示设备获得已修改数据的唯一副本。设备必须缓存该数据，并在使用结束后写回。

3.2.5.2 设备/主机 Snoop-GO-Data 假设

GO 对同一地址的后续侦听具有可见性约束。主机发送 GO 后，紧随其后的同地址侦听应观察到该 GO 所造成的状态变化。主机发出侦听后，在收齐侦听响应和隐式写回数据之前，不得向同一地址的设备请求发送 GO。对于读请求，数据可以先于 GO 到达并被设备使用，但 GO 决定最终缓存状态以及是否存在错误；在 GO 尚未发送时，主机不能对该地址发起侦听。

3.2.5.3 Snoop/WritePull 假设

对同一个 64 字节地址，主机不得同时保持 WritePull 和 H2D Snoop 活跃。主机必须收齐 WritePull 数据后才能发起侦听；反过来，也必须收齐侦听响应及可能的转发数据后才能发起 WritePull。违反该规则会使 D2H Data 的 Bogus 标志失去可靠性。

3.2.5.4 驱逐时的侦听响应与数据传输

若设备已经发出 Evict，但尚未处理 WritePull，此时侦听命中写回项并改变了缓存状态，设备必须记录该命中。设备随后处理 WritePull 时，应在所有 D2H Data 中设置 Bogus，通知主机驱逐数据可能已经陈旧，因为最新数据已经作为隐式写回数据返回。

3.2.5.5 同一地址的多个侦听

对每台设备、每个缓存行地址，主机同一时刻只允许有一个未完成侦听。发送下一次侦听前，必须收齐前一次侦听响应及全部隐式写回数据。

3.2.5.6 同一缓存行的多个读取

只有在主机跟踪状态不受处理顺序影响时，才允许同一缓存行存在多个读取。主机可以自由重排请求，因此需要排序时由设备负责。对主机内存，可并行执行多个 RdCurr 和/或 CLFlush；对使用 HDM-D 的 Type 2 设备，设备附加内存还允许多个 RdOwnNoData 偏置翻转请求。

3.2.5.7 同一缓存行的多个驱逐

不允许同一缓存行同时存在多个 Evict。Evict 向主机保证该缓存行不再存在于设备缓存；若中间没有一次可缓存 Read/Read0，又对同一行再次 Evict，就构成一致性违例。

3.2.5.8 同一缓存行的多个写请求

同一缓存行可以同时存在多个 WrInv、WOWrInv、ItoMWr 或 WrCur。主机或交换机可以重排请求，设备也可能以不同顺序收到 H2D Response。不过，在要求严格顺序时，建议设备对同一缓存行最多只保留一个未完成写，并依次发出多个写请求。

3.2.5.9 同一缓存行的多个读写请求

设备可以并行发出 RdCur、CLFlush、WrInv、WOWrInv、ItoMWr 和 WrCur。其他读取必须序列化：只有同地址之前的全部访问都收到 GO 后才能发出；该序列化读取收到 GO 之前，也不得再发出其他同地址访问。

3.2.5.10 普通全局观察（GO）

普通 GO 只有在主机保证请求者将获得目标缓存行的下一所有权后才会发送。GO 通过 MESI 状态给出允许的缓存状态，或表示数据只能使用一次，并指出是否发生错误。

3.2.5.11 宽松全局观察（FastGO）

FastGO 只适用于不要求严格排序的请求。当请求在某个实现相关子域（例如 CPU 插槽）内已保证获得下一所有权时，主机即可返回 FastGO，而不必等到整个系统范围都可观察。需要完成消息的请求最终通过 ExtCmp 表示已经在全系统范围内完成。设备只有明确知道 FastGO 边界及数据消费者位于该层级内时才能提前使用，否则必须等待 ExtCmp。

3.2.5.12 驱逐到设备附加内存

不允许通过 CXL.cache 把设备 Evict 发往设备附加内存。驱逐应直接进入设备自己的内存；但设备可以使用 ItoMWr、WrCur 等非 Evict 写，通过主机把数据写入设备附加内存。

3.2.5.13 CXL.cache 上的内存类型

设备通常通过 CXL.io ATS 请求获得主机物理地址（HPA）。ATS 完成响应会指出某个 HPA 是否只能通过 CXL.io 访问；若是，设备不得在 CXL.cache 上对该地址发请求。设备本地 HDM 范围内的地址既可通过 ATS 获得，也可通过设备专用机制获得。

3.2.5.14 一般假设

主机不保证保持设备提交 CXL.cache 请求的顺序，需要顺序时必须由设备维护。读事务中，GO 表示缓存行的下一所有权，Data 表示相对其他事务的顺序；写事务中，GO 同时表示所有权和事务顺序。收到 GO-E 或 GO-M 后，设备可以缓存所有权并在内部排序写。数据传输必须按自然分块顺序连续发送，不得与其他缓存行交错。侦听响应不得依赖其他通道；H2D Response 和 H2D Data 必须能独立排空。主机不得为未修改的数据返回 GO-M，也不得把未修改数据写回内存。除 WOWrInv/WOWrInvF 外，其他写均为强排序。

3.2.5.15 Buried Cache State 规则

Buried Cache State 指设备发送某缓存行的 CXL.cache 请求时，设备一致性引擎（DCOH）中登记的缓存状态。设备不得在 M/E/S 状态下发出普通 Read 或 Read0-Write；不得在 M/E 状态下发出 RdOwnNoData；各类 Evict 必须与实际状态匹配，例如只有 M 状态才能发 DirtyEvict。CacheFlushed 表示设备所有缓存都已刷空，因此只要仍有任何缓存行处于 M/E/S 状态就不得发送。完整允许矩阵见表 3-28。

3.2.5.16 指向设备附加内存的 H2D Req

H2D Req 通常用于侦听设备先前从同一主机获得的缓存行。虽然 Type 2 设备附加内存的一致性主要通过 M2S Req 管理，但主机可以因为粗粒度跟踪或专有 RAS 等原因，对比严格必要范围更多的缓存对等体发起侦听。因此，设备必须能够正确处理落入设备附加内存范围的 H2D Req，而不能假定这种请求永远不会出现。

3.3 CXL.mem

3.3.1 引言

CXL.mem 是主设备（Master）与从设备（Subordinate）之间访问设备附加内存的事务接口。传统方向中，主机/交换机一侧是 Master，内存设备一侧是 Subordinate；直接 P2P 场景可增加反向的一组通道，使加速器能够作为请求方访问对等 Type 3 内存。

M2S 方向包含三类消息：无数据请求 Req、带数据请求 RwD、反向失效响应 BIRsp。S2M 方向也包含三类消息：无数据响应 NDR、带数据响应 DRS、反向失效侦听 BISnp。每类消息均支持 68B、256B 和 PBR Flit 三种格式。

3.3.2 CXL.mem 通道说明

CXL.mem 各通道原则上相互独立，以保证前向进展。特定排序例外及通道间要求见规范 3.4 和 3.3.11。常规设备接口包含六条主存协议通道；支持直接 P2P 的设备再增加六条方向反转的通道。支持 HDM-DB 的设备必须支持 BI* 通道；MLD 与 G-FAM 设备可利用 HDM-DB 实现多主机一致性和直接 P2P。

图 3-18：设备侧 CXL.mem 通道

Figure 3-18

图 3-18：常规 Host/Switch Master 与 Mem Subordinate 之间的六条通道，以及直接 P2P 使用的反向六通道。

图 3-19：主机侧 CXL.mem 通道

Figure 3-19

图 3-19：Host Master Mem 与 Device/Switch Mem Subordinate 之间的 M2S Req/RwD/BIRsp 和 S2M NDR/DRS/BISnp 通道。

3.3.2.1 面向加速器的直接 P2P CXL.mem

在特定拓扑中，Type 1、Type 2 或 Type 3 加速器可选择通过 CXL.mem 与对等 Type 3 内存通信。该能力使用额外的、方向与常规 CXL.mem 相反的六条通道。这些通道只存在于设备与其直连交换机下游端口之间。由于 CXL.mem 消息并非都含有足够路由信息，PBR 路由是必需的；交换机边缘 DSP 使用 FAST 和 LDST 表把请求路由到正确目的地。

3.3.2.2 直接 P2P CXL.mem 的侦听处理

使用直接 P2P 的设备仍可能在 H2D Req 上收到同地址侦听，或从对等设备收到 S2M BISnp。设备必须记录某缓存行最初通过哪个接口请求，并在同一接口上正常响应侦听。若侦听从另一个接口到达，设备应当表现为没有缓存该地址，返回 RspIHitI 或 BIRspI，且不得改变真实缓存行状态。

3.3.3 Back-Invalidate Snoop

Back-Invalidate 机制让内存设备能够要求主机或对等请求方失效其缓存副本。内存侧通过 S2M BISnp 发起侦听；请求方通过 M2S BIRsp 返回结果。HDM-DB 使用该机制由设备侧解决一致性。块级 Back-Invalidate 可以一次覆盖多个连续缓存行，但必须遵守地址对齐、块编码和逐行响应规则。

3.3.4 内存 QoS 遥测

3.3.4.1 QoS 遥测概述

CXL.mem 提供负载反馈，使主机或对等请求方能够根据内存设备的拥塞程度调整请求注入速率。设备在 NDR/DRS 中报告 DevLoad；请求方通过 LoadMax 等状态形成节流参考。该机制的目标是缓解设备内部资源、介质带宽或共享链路成为瓶颈时的持续排队，同时不破坏协议前向进展。

3.3.4.2 主机/对等方支持的参考模型

主机或对等方根据 DevLoad 指示提高、保持或降低请求速率。调整是建议性的控制环：负载升高时逐步收紧，负载下降时逐步放宽，并避免因瞬时波动产生剧烈振荡。表 3-29 和表 3-30 给出 DevLoad 对节流的影响以及推荐调整方式。

3.3.4.3 内存设备支持

设备根据内部资源利用率计算 IntLoad，再综合链路、介质、共享端口、LD/MLD/GFD 资源及 RPID 带宽管理因素形成 DevLoad。设备应让报告值反映最限制性能的资源，并按规范规定的迟滞和更新规则变化。表 3-31 至表 3-33 给出计算因素和多逻辑设备场景下的额外考虑。

3.3.5 M2S Request（Req）

M2S Req 是 Master 发给 Subordinate 的无数据请求。字段包括 Opcode、地址、MetaField/MetaValue、SnpType、Tag、LD-ID/路由信息等，具体位宽随 Flit 格式变化。Opcode 覆盖内存读、预取、前递读写及其他控制语义。元数据用于 HDM-D/HDM-DB 一致性解析；SnpType 指示是否以及如何对主机缓存执行侦听。字段、Opcode、元数据状态和合法用法见表 3-34 至表 3-39。

3.3.6 M2S Request with Data（RwD）

M2S RwD 是携带数据的 Master-to-Subordinate 请求，典型用途是内存写。除请求头外，它还携带数据、字节使能、Poison 和可选 Trailer。Metadata 字段可要求 DCOH 在写入过程中更新一致性状态。表 3-40 至表 3-42 给出字段、Opcode 和合法组合。

3.3.6.1 RwD Trailer Present（256B Flit）

在 256B Flit 模式中，RwD 可通过 Trailer Present 指示附加尾部。尾部的长度和组成由消息格式决定，用于携带完整性或附加协议信息；编码见表 3-43。

3.3.7 M2S Back-Invalidate Response（BIRsp）

BIRsp 是 Master 对 S2M BISnp 的响应。它回显请求标签并报告目标缓存行是否已失效、是否命中以及是否存在错误。对块级侦听，主机可按规范要求逐缓存行响应或使用允许的聚合响应。字段和 Opcode 见表 3-44、表 3-45。

3.3.8 S2M Back-Invalidate Snoop（BISnp）

BISnp 是 Subordinate 发给 Master 的反向失效侦听。消息携带目标地址、Tag、Opcode 和块控制信息。它使设备侧一致性逻辑能够收回或确认主机/对等缓存中的副本。字段及 Opcode 见表 3-46、表 3-47。

3.3.8.1 块级 Back-Invalidate Snoop 规则

块级 BISnp 通过 Address[7:6] 中的 Blk 编码覆盖多条连续缓存行。地址必须按覆盖块对齐。响应方必须处理块内每一行，并按规范允许的方式提供逐行或聚合响应；在一个块事务完成前，不得造成无法解析的同地址重叠。Blk 编码见表 3-48。

3.3.9 S2M No Data Response（NDR）

NDR 是不带数据的 Subordinate-to-Master 响应。它携带 Tag、Opcode、错误/毒化相关状态、元数据结果以及 DevLoad。Master 使用 Tag 与原始 Req/RwD 关联。NDR 字段、Opcode 和 DevLoad 编码见表 3-49 至表 3-51。

3.3.10 S2M Data Response（DRS）

DRS 是带数据的 Subordinate-to-Master 响应，用于返回内存读数据。除 Tag 和 Opcode 外，它还携带 Poison、元数据、DevLoad、分块信息以及可选 Trailer。DRS 可能以多个数据块组成完整缓存行，接收方必须按自然顺序重组。字段和 Opcode 见表 3-52、表 3-53。

3.3.10.1 DRS Trailer Present（256B Flit）

在 256B Flit 模式下，DRS 可带尾部；TRP 可由其他字段组合推导。尾部布局和长度见表 3-54。

3.3.11 前向进展与排序规则

CXL.mem 通道通常独立运行，但某些事务存在显式依赖。实现不得让 Req、RwD、NDR、DRS、BISnp 与 BIRsp 形成循环等待。带转发语义的 MemRdFwd/MemWrFwd、弱排序写、反向失效以及数据响应必须遵守规范定义的完成与可见性边界。主机生成的弱排序写可以在允许条件下越过其他事务，但最终完成消息仍建立系统范围的观察点。

3.3.11.1 HDM-D/HDM-DB 的 Buried Cache State 规则

对于 HDM-D/HDM-DB，Req 与 RwD 的 Opcode 是否允许取决于 DCOH 中埋藏的缓存状态。设备必须在发请求前检查状态，避免同时声明互相矛盾的所有权或元数据转换。表 3-55 给出各 Opcode 在不同状态下的允许矩阵。

术语表

规范术语	中文译法	说明
CXL.cache	CXL.cache 缓存一致性协议	保留协议名，不译成“缓存”
CXL.mem	CXL.mem 内存协议	保留协议名
Host	主机	一致性域中的主机侧代理
Device	设备	CXL 设备侧代理
Master	主设备/请求方	CXL.mem 中发起事务的一侧
Subordinate	从设备/响应方	CXL.mem 中响应事务的一侧
D2H / H2D	设备到主机 / 主机到设备	CXL.cache 通道方向
M2S / S2M	Master 到 Subordinate / Subordinate 到 Master	CXL.mem 通道方向
GO	全局观察	Global Observation
FastGO	宽松全局观察	子域内先行建立可见性的 GO
ExtCmp	扩展完成	系统范围内的最终完成指示
WritePull	写数据拉取	主机要求设备发送写数据
Snoop	侦听	为维护缓存一致性发出的查询/失效请求
BISnp / BIRsp	反向失效侦听 / 反向失效响应	HDM-DB 的设备侧一致性机制
NDR / DRS	无数据响应 / 数据响应	CXL.mem S2M 响应类型
Req / RwD	无数据请求 / 带数据请求	CXL.mem M2S 请求类型
HDM-D / HDM-DB	主机管理设备内存的设备一致性模式	HDM-DB 增加 Back-Invalidate
Buried Cache State	埋藏缓存状态	DCOH 中登记的请求发出时缓存行状态

原文协议表

以下表格均为规范原文裁图。中文正文解释字段用途，但数值、位宽与 Opcode 以原图为准。

3.2 CXL.cache 表格

表格	原文图片
Table 3-12 Channel Crediting Summary
Table 3-13 D2H Request Fields, sheet 1
Table 3-13 D2H Request Fields, sheet 2
Table 3-14 Non Temporal Encodings
Table 3-15 D2H Response Fields
Table 3-16 D2H Data Header Fields
Table 3-17 H2D Request Fields, sheet 1
Table 3-17 H2D Request Fields, sheet 2
Table 3-18 H2D Response Fields
Table 3-19 RSP_PRE Encodings
Table 3-20 Cache State Encoding
Table 3-21 H2D Data Header Fields
Table 3-22 Device to Host Requests
Table 3-23 D2H Requests targeting non-device memory
Table 3-24 D2H Requests targeting device memory
Table 3-25 D2H Response Encodings
Table 3-26 H2D Requests to D2H Responses
Table 3-27 H2D Response Opcode Encodings
Table 3-28 Allowed D2H Opcodes per Buried State

3.3 CXL.mem 表格

表格	原文图片
Table 3-29 DevLoad and throttling
Table 3-30 Recommended throttling adjustment
Table 3-31 Factors for IntLoad
Table 3-32 MLD DevLoad factors, sheet 1
Table 3-32 MLD DevLoad factors, sheet 2
Table 3-33 MLD/GFD DevLoad factors
Table 3-34 M2S Request Fields, sheet 1
Table 3-34 M2S Request Fields, sheet 2
Table 3-35 M2S Req Opcodes, sheet 1
Table 3-35 M2S Req Opcodes, sheet 2
Table 3-36 Metadata Field Definition
Table 3-37 Meta0-State Values
Table 3-38 Snoop Type Definition
Table 3-39 M2S Req Usage
Table 3-40 M2S RwD Fields, sheet 1
Table 3-40 M2S RwD Fields, sheet 2
Table 3-41 M2S RwD Opcodes
Table 3-42 M2S RwD Usage
Table 3-43 RwD Trailers
Table 3-44 M2S BIRsp Fields
Table 3-45 M2S BIRsp Opcodes
Table 3-46 S2M BISnp Fields
Table 3-47 S2M BISnp Opcodes
Table 3-48 Block Enable Encoding
Table 3-49 S2M NDR Fields
Table 3-50 S2M NDR Opcodes, sheet 1
Table 3-50 S2M NDR Opcodes, sheet 2
Table 3-51 DevLoad Definition
Table 3-52 S2M DRS Fields, sheet 1
Table 3-52 S2M DRS Fields, sheet 2
Table 3-53 S2M DRS Opcodes
Table 3-54 DRS Trailers
Table 3-55 Allowed HDM-D/HDM-DB Req/RwD Opcodes