目录
CXL.mem 称为 CXL 内存协议，它是 CPU 和内存之间的事务接口。当在芯片之间通信时，它使用 CXL 的物理层和链路层。该协议可用于多种不同的内存连接选项，包括内存控制器位于主机 CPU 中、内存控制器位于加速器设备中，或者内存控制器移动到内存缓冲芯片中。它适用于不同类型的内存(例如，易失性、持久性等)和配置(例如，扁平、分层等). CXL.mem 为 CXL.mem 协议暴露的主机管理设备内存(HDM)地址区域提供了三种基本的一致性模型:(在主机和设备之间的 CXL.mem 路径上的地址区域视图必须一致)
- HDM-H(仅主机一致性): 仅用于类型 3 设备
- HDM-D(设备一致性): 仅用于依赖 CXL.cache 来管理与主机一致性的传统类型 2 设备
- HDM-DB(使用回退失效的设备一致性): 可用于类型 2 设备或类型 3 设备
一致性机制(CACHE COHERENCY)在 CPU 和内存之间通过 CXL.mem 的请求和响应实现。在这种配置中，CPU 一致性机制被视为 CXL.mem 主设备(Master)，而内存设备被视为 CXL.mem 从设备(Subordinate). CXL.mem 主设备负责发出 CXL.mem 请求(例如，读、写等)，而 CXL.mem 从设备负责响应 CXL.mem 请求(例如，数据、完成等).
当从设备映射 HDM-D/HDM-DB 时，CXL.mem 协议假定存在设备一致性引擎(DCOH), 该代理负责实现一致性相关功能，例如基于 CXL.mem 命令的设备缓存探测和元数据字段的更新. 对元数据内存的支持是可选的，但需要事先与主机协商. 如果设备连接的内存不支持元数据，从设备仍需使用主机提供的元数据更新来解释命令。如果设备连接的内存支持元数据，则主机可以使用它来实现 CPU 插槽的粗粒度探测过滤器。在 HDM-H 地址区域，使用由主机定义。协议允许存储和返回 2 位元数据。
从主设备到从设备的 CXL.mem 事务称为 ‘M2S’，从从设备到主设备的事务称为 ‘S2M’。在 M2S 事务中，有三类消息:
- 无数据的请求: 通称为请求(Req)
- 带数据的请求(RwD)
- 回退失效响应(BIRsp)
类似地，在 S2M 事务中，有三类消息:
- 无数据的响应: 通称为无数据响应(NDR)
- 带数据的响应: 通称为数据响应(DRS)
- 回退失效探测: BISnp
CXL.mem Channel
通常情况下，CXL.mem 通道彼此独立工作，以确保持续进行. CXL.mem 的设备接口定义了如图所示的 6 个通道。类型 2 设备必须支持 BI 通道(S2M BISnp 和 M2S BIRsp)，以支持这些设备中的 HDM-DB 内存区域。使用 HDM-D 内存区域的类型 2 设备可能不具备 BI 通道。类型 3 设备(内存扩展) 可能支持 HDM-DB 以支持直接点对点通信(P2P)。MLD 和 G-FAM 设备可能使用 HDM-DB 以实现多主机一致性。HDM-DB 区域将由软件识别，并在解码寄存器中进行编程，这些区域将遵循协议流.
对于主机和交换机，通道数量在图中定义, 通道定义与设备相同.
Back-Invalidation Snoop
为了使设备能够实现用于跟踪主机缓存的包容性探测过滤器，会从设备发起回退失效探测(BISnp)，以更改主机的缓存状态. 对于 CXL 而言，包容性探测过滤器的定义是跟踪缓存线粒度主机缓存的设备结构，其大小有限，仅为设备支持的主机物理地址空间的一小部分. 在 68B flits 中，只有 CXL.cache D2H 请求流可以用于管理与主机的一致性. 此流用于具有 HDM-D 内存属性的地址, 此流的一个主要限制是 D2H 请求通道可能会被阻塞，等待 M2S 请求通道的前进，从而不允许包容性探测过滤器架构。对于 HDM-DB 内存区域，使用 BISnp 通道(而不是 CXL.cache) 来解决一致性问题。CXL 主机实现可能在一个根端口下有 HDM-DB 和 HDM-D 的混合设备。
QoS Telemetry for Memory
内存的 QoS 遥测(Qos Telemetry)机制使内存设备能够在每个 CXL.mem 请求的响应消息中，指示其当前的负载水平(DevLoad). 这使得主机能够根据设备的负载水平，调节对设备部分、单个设备或设备组的 CXL.mem 请求速率，从而在优化这些内存设备性能的同时限制结构的拥堵。这对于包含多种内存类型(例如，DRAM 和持久性内存) 和多逻辑设备(MLD)组件的 CXL 层次结构尤为重要。
QoS 遥测的某些方面是当前 CXL 内存设备的强制要求，而其他方面则是可选的。CXL 交换机对支持 QoS 遥测没有独特要求。QoS 遥测的总体目标是让内存设备向其关联的主机提供即时和持续的 DevLoad 反馈，用于动态调整主机请求速率限制。如果某个设备或一组设备变得过载(Overloaded)，关联的主机会增加请求速率限制的量。如果这些设备未被充分利用，关联的主机将减少请求速率限制的量。QoS 遥测的设计旨在帮助主机避免过度补偿和不足补偿。主机内存请求速率限制是可选的，主要取决于具体实现。
为了更优化地支持多种内存类型的内存设备，一个设备可以实现多个 QoS 类，这些类是识别的流量集，设备在这些流量集之间支持差异化的 QoS 和显著的性能隔离。例如支持 DRAM 和持久性内存的设备可能会实现两个 QoS 类，每种受支持的内存类型各一个。提供显著的性能隔离可能需要独立的内部资源(例如每个 QoS 类的单独请求队列). MLD(多逻辑设备) 在每个逻辑设备(LD) 基础上提供差异化的 QoS。当 MLD 变得过载时，MLD 有架构控制指定每个 LD 的分配带宽份额。当 MLD 未过载时，LD 可以使用超过其分配带宽份额的带宽，直至基于设备最大持续带宽的指定份额限制。CXL 1.1 内存设备的 DevLoad 指示将始终显示为轻负载，这允许这些设备尽其所能与支持 QoS 遥测的主机一起操作，尽管它们无法由主机主动测量其内存请求速率。使用轻负载而不是最佳负载的原因是，任何 CXL 1.1 设备如果与当前内存设备共享相同的主机限制范围，它们指示最佳负载将会掩盖任何当前设备指示的轻负载.
Host Support of QoS Telemetry
强烈建议主机支持 QoS 遥测，但这不是强制性的。QoS 遥测没有为主机 QoS 遥测提供架构控制。然而如果主机为给定根端口下的多个不同内存设备集实现独立限流，则限流必须基于 HDM 范围，这些范围被称为主机限流范围。本节中的参考模型涵盖了主机应如何支持 QoS 遥测的推荐方面。这些方面不是强制性的，但它们应该有助于最大限度地提高 QoS 遥测在优化内存设备性能、提供差异化 QoS 和减少 CXL 结构拥塞方面的有效性. 假设每个主机在限流范围基础上支持不同的限流级别，表示为 Throttle[Range]。Throttle[Range] 由概念参数 NormalDelta 和 SevereDelta 定期调整。在每个采样周期内，对于给定的 Throttle[Range]，主机记录该限流范围内报告的最高 DevLoad 指示，称为 LoadMax.
对 Throttle[Range] 的任何增量或减量都不应分别超过或低于合法值。Throttle[Range] 预计会定期调整，每 tH 纳秒进行一次，除非需要更及时的调整。tH 参数应由特定平台的软件进行配置，并且理想情况下可以基于每个限流范围进行配置。当 tH 到期时，主机应根据 LoadMax 更新 Throttle[Range]，如表所示，然后将 LoadMax 重置为其最小值。往返结构时间是请求消息从主机到设备的时间加上响应消息从设备到主机的时间之和。tH 的最佳值预计比相关设备组的平均往返结构时间略长(例如几百纳秒). 为了避免主机的过度补偿，需要一些时间来使响应中的 DevLoad 指示流反映最后一次 Throttle[Range] 调整，然后主机再进行新的调整。如果主机收到中等过载或严重过载的指示，强烈建议主机立即进行限流调整，而不必等待当前 tH 采样周期结束。随后，主机应重置 LoadMax，然后等待 tH 纳秒再进行额外的限流调整，以避免过度补偿.
Memory Device Support for QoS Telemetry
QoS Telemetry Register Interfaces: MLD 必须支持 MLD 组件命令集中的指定 MLD 命令集。这些 MLD 命令提供了对架构功能、控制和状态寄存器的访问，供 Fabric Manager 通过 FM API 使用. 如果 SLD 支持内存设备命令集，则必须支持指定的 SLD QoS 遥测命令集. 这些 SLD 命令通过 CXL 设备寄存器接口提供对架构功能、控制和状态字段的访问，供系统软件管理. 每个架构 QoS 遥测寄存器都是通过上述 MLD 命令、SLD 命令或两者均可访问的寄存器.
Memory Device QoS Class Support: 每个 CXL 内存设备可以支持一个或多个 QoS 类。预计的典型数量是一个到四个，但不排除更高的数量。如果设备只支持一种介质，通常只支持一个 QoS 类。如果设备支持两种介质，通常会支持两个 QoS 类. 支持多个 QoS 类的设备称为多 QoS 设备. 尽管如此，强烈建议多 QoS 设备独立跟踪和报告不同 QoS 类的 DevLoad 指示，并且在实现中尽可能在不同 QoS 类之间提供性能隔离.
Memory Device Internal Loading(IntLoad): CXL 内存设备必须持续跟踪其内部负载(称为 IntLoad). 多 QoS 设备应在每个 QoS 类的基础上进行跟踪。设备必须至少基于其内部请求队列确定 IntLoad。例如一个简单的设备可以通过监控瞬时请求队列深度来决定报告四种 IntLoad 指示中的哪一种。它还可以结合其他内部资源利用情况，如下表:
IntLoad 的确定方法是特定于设备的，但强烈建议多 QoS 设备为每个 QoS 类实现独立的请求队列。对于复杂设备，建议它们基于超出请求队列深度监控的内部资源利用情况来确定 IntLoad。尽管本节描述的 IntLoad 是决定设备响应中返回哪种 DevLoad 指示的主要因素，但根据情况可能还需要考虑其他因素.
Egress Port Backpressure: 即使在持续的轻负载下，内存设备的出口端口也可能会遇到流量控制反压。如果一个根端口(RP) 被开关下的多个内存设备超额订阅(Oversubscribed)，这种情况很容易发生。长时间的出口端口反压通常表明设备与根端口之间的一个或多个上游流量队列已满，从设备到主机的响应传递显著延迟。这使得 QoS 遥测反馈回路响应较慢，并降低了整体机制的有效性。出口端口反压是一种可选的规范机制，用于帮助缓解这种情况的负面影响.
Egress Port Backpressure Leading to Larger Request Queue Swings: 当 QoS 遥测反馈回路响应较慢时，设备的请求队列深度比正常情况下更容易出现较大波动. 当队列深度增加时，主机接收中等过载或严重过载指示的延迟会导致队列比正常情况下更满，在极端情况下完全填满，迫使入口端口对进入的下游流量施加反压. 当队列深度减少时，主机接收轻负载指示的延迟会导致队列比正常情况下更空，极端情况下完全清空，从而不必要地降低设备吞吐量。使用出口端口反压机制有助于避免设备与其根端口(RP)之间的上游流量队列长时间填满，减少设备到主机响应的延迟。这使得 QoS 遥测反馈回路更具响应性，有助于避免请求队列的过度波动.
Minimizing Head-of-Line Blocking with Upstream Responses from MLDs: 当 MLD 和一个或多个拥塞的根端口(RP)之间的一个或多个上游流量队列变满时，与这种拥塞相关的首线阻塞(HOL)可能会延迟或阻塞针对未拥塞的其他根端口的流量。长时间的出口端口反压通常表明设备上方的下游交换端口的入口端口队列经常满。该队列中针对拥塞根端口的响应可能会阻塞针对未拥塞根端口的响应，从而不必要地降低整体设备吞吐量。使用出口端口反压机制有助于减少承载上游流量的队列的平均深度。这减少了针对未拥塞根端口的流量延迟，增加了整体设备吞吐量.
出口端口拥塞支持能力位和出口端口拥塞启用控制位是架构化的 QoS 遥测位，它们指示对这一可选机制的支持以及启用或禁用该机制的方法。架构化的反压平均百分比状态字段返回当前测量的出口端口平均拥塞情况的快照。QoS 遥测为出口端口经历流量控制反压的时间百分比设定了两个阈值。这种情况定义为出口端口有 flit 或消息等待传输，但由于缺乏合适的流量控制信号而无法传输它们。如果拥塞时间的百分比大于或等于出口中等百分比，设备可能返回中等过载的 DevLoad 指示。如果拥塞时间的百分比大于或等于出口严重百分比，设备可能返回严重过载的 DevLoad 指示。给定响应返回的实际 DevLoad 指示也可能是其他因素的结果.
Temporary Throughput Reduction: 在某些条件下，设备可能会暂时降低其吞吐量。设想的例子包括正在进行介质维护的非易失性存储器(NVM)设备、由于功耗/热量原因减少吞吐量的设备，以及执行刷新操作的 DRAM 设备。如果设备在短时间内显著降低其吞吐能力，可以通过在这种情况发生前不久并且只在真正必要时，在其响应中指示中等过载或严重过载，以帮助缓解这种情况。这是一种特定于设备的可选机制。临时吞吐量减少机制可以向相关主机提供前瞻性提前警告，主机可以及时增加其限流，以避免设备的内部请求队列填满并可能导致入口端口拥塞。提供提前警告的最佳时间高度依赖于设备，并且取决于多个因素，包括当前请求率、设备内部缓冲的数量、吞吐量减少的水平/持续时间以及结构往返时间。设备不应在不必要的情况下使用该机制。例如，如果设备当前处于轻负载状态，可能没有必要或不适合在准备即将发生的事件时指示过载情况。同样，指示过载情况的设备不应在不再需要时继续指示过载情况。临时吞吐量减少支持能力位和临时吞吐量减少启用控制位是架构化的 QoS 遥测位，它们指示对这一可选机制的支持以及启用或禁用该机制的方法.
Avoid Unnecessary Use of Temporary Throughput Reduction: 理想情况下，设备的设计应限制其临时吞吐量减少事件的严重性和持续时间，以至于不需要使用这种机制.
DevLoad Indication by Multi-QoS and Single-QoS SLDs: 对于 SLD(单逻辑设备)，每个响应中返回的 DevLoad 指示由设备的 IntLoad(内部负载)、出口端口拥塞状态和临时吞吐量减少状态中的最大值决定. 例如，如果 IntLoad 指示轻负载，出口端口拥塞指示中等过载，而临时吞吐量减少不指示过载，则响应的最终 DevLoad 指示为中等过载.
DevLoad Indication by Multi-QoS and Single-QoS MLDs: 对于 MLD(多逻辑设备)，每个响应中返回的 DevLoad 指示由与 SLD 相同的因素决定，并增加了一些用于在每个逻辑设备(LD) 基础上提供差异化 QoS 的因素。架构控制指定每个 LD 分配的带宽，当 MLD 过载时，各 LD 的带宽分配为总 LD 流量的一部分。当 MLD 未过载时，LD 可以使用超过其分配带宽的一部分，直到根据设备最大持续带宽的指定限额为止，这与整体 LD 活动无关。每个 LD 的带宽利用率基于当前正在服务的请求以及最近完成的请求历史来连续测量。当前正在服务的请求由 ReqCnt[LD] 计数器跟踪，每个 LD 有一个计数器。每次收到该 LD 的请求时，相应的 ReqCnt 计数器增加. 每次该 LD 发送响应时，相应的 ReqCnt 计数器减少. ReqCnt 反映了瞬时已承诺利用率，允许快速反映传入请求，特别是当请求成批到来时。
最近完成请求的历史由 CmpCnt[LD, Hist] 寄存器跟踪，每个 LD 有一组 16 个 Hist 寄存器。MLD 的一个可配置的完成收集间隔控制器决定了在活动(最新) Hist 寄存器/计数器中计数传输响应的时间间隔。每个间隔结束时，LD 的 Hist 寄存器值从新的移动到旧的，最旧的值被丢弃，活动(最新) 的 Hist 寄存器/计数器被清除. LD 带宽管理的控制包括每个 LD 的一组寄存器，称为 QoS 分配系数 [LD]和 QoS 限制系数 [LD]。对于每个 LD，QoS 分配系数指定分配给该 LD 在所有其 QoS 类中的当前设备利用率的分数。每个 LD 的 QoS 限制系数指定作为固定限制的该 LD 在所有其 QoS 类中的最大持续设备利用率的分数，与整体 LD 活动无关.
每个 LD 的带宽利用率基于其关联的 ReqCnt 和 CmpCnt[Hist] 计数器/寄存器的总和。CmpCnt[Hist] 反映最近完成的请求，完成收集间隔控制了这段历史的覆盖时间(即完成的请求被忘记的速度)。CmpCnt 反映了最近的利用率，帮助避免对请求突发的过度补偿。ReqCnt 和 CmpCnt[Hist] 共同提供了一种简单、公平且可调的方式来计算平均利用率。较短的响应历史强调瞬时已承诺利用率，提高响应能力。较长的响应历史平滑了平均利用率，减少了过度补偿. ReqCmpBasis 是一个架构控制寄存器，它提供了限制每个 LD 设备利用率的基础，与整体 LD 活动无关。因为 ReqCmpBasis 是与 ReqCnt[]和 CmpCnt[] 之和进行比较的，它的最大值必须基于所有活动 LD 的 ReqCnt[] 和 CmpCnt[] 的最大值之和。Sum(ReqCnt[]) 的最大值是设备内部排队和它能同时处理的请求数量的函数。Sum(CmpCnt[,*]) 的最大值是设备在完成历史记录的期间的最大请求服务速率的函数，直接受到完成收集间隔设置的影响.
FM 编程 ReqCmpBasis、QoS 分配系数数组和 QoS 限制系数数组，以控制 LD 之间的差异化 QoS。FM 可以将 ReqCmpBasis 降低到其最大持续估算值以下，作为限制功耗和热量散发的手段。设备执行以下计算来确定每个响应中返回的 DevLoad 指示.
- LD 始终受其 QoS 限制系数的约束
- 对于轻负载或最佳负载的总负载指示，LD 可以超过其 QoS 分配系数，最多可达其 QoS 限制系数
- 对于中等过载或严重过载的总负载指示，负载在 QoS 分配系数范围内的 LD 仍可以保持其分配的带宽
Egress Port Congestion Measurement Mechanism: 这种硬件机制以滚动百分比的方式测量出口端口的平均拥塞情况:
- FCBP(流量控制反压): 这种二进制条件表示出口端口的瞬时状态。如果端口有可传输的消息或 flit，但由于缺乏合适的流量控制信号而无法传输，则为真
- 反压采样间隔寄存器: 这个架构控制寄存器指定以纳秒为单位的固定间隔采样 FCBP, 范围是 0-31。记录 100 个样本，因此设置为 1 时表示 100 纳秒的历史。设置为 31 时表示 3.1 微秒的历史。设置为 0 时禁用测量机制，必须指示平均拥塞百分比为 0.
- BPhist[100]位数组: 这个数组存储最近的 100 个 FCBP 样本, 软件无法访问它.
- 反压平均百分比: 当读取这个架构状态寄存器时，它指示 BPhist[100] 中当前设置位的数量，值范围为 0 到 100.
BPhist[100] 和反压平均百分比的实际实现因设备而异。这里是一个可能的实现方法:
- BPhist[100] 是一个移位寄存器
- 反压平均百分比是一个上下计数器
- 每个新的 FCBP 样本:
- 如果新样本(尚未在 BPhist 中) 和 BPhist 中的最旧样本都是 0 或都是 1，则反压平均百分比不变
- 如果新样本是 1 且最旧样本是 0，则反压平均百分比增加
- 如果新样本是 0 且最旧样本是 1，则反压平均百分比减少
- 移动 BPhist[100]，丢弃最旧的样本并输入新的样本
Recent Transmitted Responses Measurement Mechanism: 这种硬件机制测量在配置的时间段内每个 LD 最近 16 个间隔内的已传输响应数量.
- 完成收集间隔寄存器: 这个架构控制寄存器指定在活动 Hist 寄存器中计数已传输响应的时间间隔。范围是 0-127。设置为 1 时表示 16 纳秒的历史。设置为 127 时表示约 2 微秒的历史。设置为 0 时禁用测量机制，必须指示响应计数为 0.
- CmpCnt[LD, 16] 寄存器: 这些寄存器按 LD 基础跟踪最近已传输响应的总数。CmpCnt[LD, 0] 是一个计数器，是最新值，而 CmpCnt[LD, 1:15] 是寄存器。这些寄存器对软件不可见
对于每个 LD，在每个完成收集间隔结束时:
- 16 个 CmpCnt[LD, *] 寄存器值从新值移动到旧值
- 丢弃 CmpCnt[LD, 15] Hist 寄存器值
- 清除 CmpCnt[LD, 0] 寄存器，并准备在下一个间隔内计数传输的响应
M2S Request(Req)
Req 消息类别通常包含从主设备到从设备的读取、失效和信号.
M2S Req Memory Opcodes
Meta Data Field Definition
Meta0-State Value Definition(HDM-D/HDM-DB Devices)
Snoop Type Definition
M2S Req Usage
M2S Request with Data(RwD)
带数据请求(RwD)消息类别通常包含从主设备到从设备的写入操作.
M2S RwD Memory Opcodes
M2S RwD Usage
S2M Back-Invalidate Snoop(BISnp)
回退失效探测(BISnp)消息类别包含从从设备到主设备的探测消息。该消息类别不支持 68B Flit 模式
S2M BISnp Opcodes
Rules for Block Back-Invalidation Snoops
块回退失效探测适用于多个自然对齐的连续缓存行(2 或 4 个缓存行). 主机必须确保每一行的一致性被解决，并且可以以任意顺序发送合并或单独的响应。在存在地址冲突的情况下，主机需要分别解决每个缓存行的冲突。这种特殊的地址编码仅适用于 BISnp*Blk 消息.
S2M No Data Response(NDR)
NDR 消息类别包含从从设备到主设备的完成和指示
S2M NDR Opcodes
表定义了在 NDR 和 DRS 消息中使用的 DevLoad 值。编码的分配方式允许与 CXL 1.1 向后兼容，使得 00b 值在主机中造成的影响最小.
DevLoad Definition
S2M Data Response(DRS)
DRS 消息类别包含从从设备到主设备的内存读取数据
S2M DRS Opcodes
Forward Progress and Ordering Rules
- Req 请求可能会被发往主机的 BISnp 阻塞，但 RwD 请求不能被发往主机的 BISnp 阻塞.
- 在 M2S Req 通道中的 CXL.mem 请求不能超过 MemRdFwd 或 MemWrFwd，如果请求和 MemRdFwd 或 MemWrFwd 是针对相同的缓存行地址. 在 M2S Req 通道中发送的 MemRdFwd 和 MemWrFwd 操作码实际上是对 CXL.cache D2H 请求的响应。某些 CXL.cache D2H 请求的响应在 CXL.mem M2S Req 通道上发送的原因是为了确保主机对同一地址的后续请求保持在其后面有序。这使主机和设备能够避免竞争条件。除此之外，Req、RwD、NDR 和 DRS 消息类别或 Req 消息类别中不同地址之间没有排序要求
- NDR 和 DRS 消息类别需要在请求源进行预分配。这保证了响应能够下沉并确保前进进展。
- 在 CXL.mem 中，写入数据只有在写入完成后才保证对后续访问可见
- CXL.mem 请求需要在设备上前进，而不依赖于任何设备发起的请求，除了 BISnp 消息。这包括设备在 CXL.io 或 CXL.cache 上的任何请求
- S2M 和 M2S 的缓存行数据传输必须在没有交错传输的情况下进行
IMPLEMENTATION NOTE: 存在两种绕过设备附加内存的情况，其中 M2S RwD 通道中的消息可以超过 M2S Req 通道中同一缓存行地址的消息
主机生成的弱序写入可能绕过 MemRdFwd 和 MemWrFwd。结果是弱序写入可能会绕过设备的较旧读或写请求
对于设备发起的 RdCurr 请求到主机，主机在解决一致性后会向设备发送 MemRdFwd. 在发送 MemRdFwd 后，主机可能拥有该行的独占副本(因为 RdCurr 不会降级目标的一致性状态)，这允许主机随后修改该行并向此地址发送 MemWr。此 MemWr 不会与之前发送的 MemRdFwd 保持顺序.
这两种情况都是合法的，因为弱序存储（在情况#1 中）和 RdCurr（在情况#2 中）不保证强一致性
Buried Cache State Rules for HDM-D/HDM-DB
CXL.mem 协议中的埋藏缓存状态(Buried Cache state) 是指当发送新的 Req 或 RwD 消息时，由主机的 Home Agent 逻辑(HA) 为缓存行地址注册的缓存行状态。该缓存状态可能是由主机控制的缓存，但不包括拥有 HDM-D/HDM-DB 内存的设备中的缓存。这些规则仅适用于设备管理一致性的 HDM-D/HDM-DB 内存. 主机发出的 CXL.mem Req/RwD 消息的埋藏缓存状态规则:
- 如果缓存行处于 Modified、Exclusive 或 Shared 状态，则不得发出 MemRd/MemRdData
- 如果缓存行处于 Modified 或 Exclusive 状态，则不得发出 MemInv/MemInvNT。设备可以请求 Exclusive 状态的所有权，作为 Shared 状态的升级请求
- 可以从 Shared 或 Exclusive 状态发出 MemClnEvct
- 只有从 I 状态发出的 MemWr 才能将 SnpType 设置为 SnpInv。对于扩展到多个主机的一致性，HDM-DB 内存区域不允许使用这种编码
- 只有从 Modified 状态发出的 MemWr 才能将 SnpType 设置为 NoOp
表总结了埋藏缓存状态下的 Req 消息和 RwD 消息的允许情况。MemRdFwd/MemWrFwd/BIConflict 被排除在该表之外，因为它们是响应消息