【CXL协议-RAS（12）】

前言：

在了解本章之前，咱们先来了解一下什么是RAS
RAS是可靠性（Reliability）、可用性（Availability）和服务性（Serviceability）的缩写，这是衡量系统设计和架构质量的关键指标。在CXL协议中，RAS功能被设计来确保数据的准确传输，减少系统错误，提供错误检测与修正机制，以及支持高效的系统管理和维护。
CXL协议的RAS特性可以细分为以下几个方面：

1.错误管理和恢复：CXL协议包含了复杂的错误管理和恢复策略，能够在检测到错误时立即采取行动，包括错误记录、传播和隔离，以保护数据的完整性和可靠性。

2.高级的错误检测：CXL利用了PCIe的高级错误报告（Advanced Error Reporting, AER）特性，能够提供更详细的错误信息，帮助快速定位问题源头，减少系统宕机时间。

3.热插拔支持：为了提高系统的可用性和服务性，CXL支持热插拔操作，使得在不关闭系统电源的情况下添加或移除设备成为可能。这对于数据中心的维护和升级尤为重要。

4.内存保护和隔离：CXL协议通过提供内存保护和隔离机制，确保了一个设备的故障不会影响到系统中的其他设备。这有助于提高系统的整体稳定性和可靠性。

5.带有冗余的设计：为了进一步提高可靠性和可用性，CXL设备和系统可以实现冗余设计，比如通过使用冗余路径和组件来提供故障转移能力。

12.0 Reliability, Availability and Serviceability

CXL RAS 功能构建在 PCI Express 之上。 引入了其他功能来解决缓存一致性和内存问题，如下所列。

12.1 Supported RAS Features（支持的 RAS 功能）

下表列出了 CXL 支持的 RAS 功能及其对 CXL.io 与 CXL.cache 和 CXL.mem 的适用性。

12.2 CXL Error Handling（CXL 错误处理）

如图180所示，CXL可以同时承载三种协议：CXL.io、CXL.cache和CXL.mem。 CXL.io 承载类似 PCIe 的语义，并且必须得到所有 CXL 端点的支持。 所有 RAS 功能都必须满足所有这些协议和用途。
有关 CXL 架构和所有协议的详细信息，请参阅本文档的其他部分。
下面的图 180 说明了 CXL 和 CXL RAS 的重点领域。 即，链路和协议RAS，适用于CXL组件到组件通信机制，以及设备RAS，仅适用于设备本身。 所有 CXL 协议错误都会通过 PCIe AER 机制作为“可纠正”反映到操作系统
内部错误”(CIE) 或“不可纠正的内部错误”(UIE)。 如果如此配置，错误也可能会反映到平台软件。

参考图180，CXL 1.1主机/根联合体位于北侧，包含所有常见的错误处理机制，例如核心错误处理（例如MCA架构）、PCIe AER、RCEC和其他平台级错误报告和处理机制 。 设备遇到的 CXL.mem 和 CXL.cache 协议错误通过 CXL.io 传达给 CPU。 记录在 PCIe AER 寄存器中。
以下各节将重点介绍链路层和事务层错误处理机制以及 CXL 设备错误处理。
CXL 2.0 端口检测到的错误将通过 CXL.io 作为 UIE/CIE 使用标准 PCIe 错误报告机制进行升级和报告。

12.2.1 Protocol and Link Layer Error Reporting（协议和链路层错误报告）

检测到协议和链接错误并将其传达给主机，在主机上可以公开和处理这些错误。 没有错误引脚将 CXL 器件连接到主机。
错误通过 CXL.io 上的消息在主机和 CXL 设备之间进行通信。

12.2.1.1 CXL 1.1 Downstream Port (DP) Detected Errors（CXL 1.1 下游端口 (DP) 检测到的错误）

CXL 1.1 DP 检测到的错误通过 UIE/CIE 等根联合体错误报告机制进行升级和报告。 下面列出了各种信令和记录步骤，并在图 181 中进行了说明。

1. DPA CXL.io 检测到的错误记录在 DPA RCRB 的本地 AER 扩展功能中。 软件必须确保 DPA AER 扩展功能中的根端口控制寄存器未配置为生成中断。
2. DPA CXL.cache 和 CXL.mem 记录 CXL RAS 能力结构中的错误（第 8.2.5.9 节）
3. DPA CXL.cache、CXL.mem 或 CXL.io 向 RCEC 发送错误消息
4. RCEC记录UIE/CIE
5. 如果启用的操作系统错误处理程序可以通过检查 RCEC AER 扩展功能开始并遵循 PCI Express 规则来发现错误源，则 RCEC 会生成 MSI。 除了 PCI Express 基本规范和本规范中定义的错误日志之外，平台软件错误处理程序还可以询问平台特定的错误日志。
   

12.2.1.2 CXL 1.1 Upstream Port (UP) Detected Errors（CXL 1.1 上行端口 (UP) 检测到的错误）

CXL 1.1 UP 检测到的错误也会通过根联合体事件收集器升级并报告。 下面列出了各种信令和记录步骤，并在图 182 中进行了说明。
6. 如果 UPZ 中的 CXL.cache 或 CXL.mem 块检测到协议或链路错误，则应将其记录在 CXL RAS 能力结构中（第 8.2.5.9 节）
7. UP RCRB 不得实施 AER 扩展能力
8. UPZ 向受此错误影响的所有 CXL.io 功能发送错误消息（此示例显示具有单一功能的设备。该消息必须包含 CXL.io 功能构建 AER 记录所需的所有详细信息
9. .IO 功能在各自的 AER 扩展功能中记录收到的消息
10. 每个受影响的 CXL.io 功能使用自己的请求者 ID 向 UPZ 发送 ERR_ 消息
11. UPZ 通过链接转发此错误消息而不记录
12. DPA将Error消息转发给RCEC
13. 如果根据 PCIe 基本规范启用，RCEC 会记录错误并发出中断信号

12.2.1.3 CXL 1.1 RCiEP Detected Errors（CXL 1.1 RCiEP 检测到的错误）

CXL 1.1 RCiEP 检测到的错误也会通过根联合体事件收集器升级和报告。 下面列出了各种信令和记录步骤，图 183 也对此进行了说明。

1. CXL.cache（或 CXL.mem）向所有受影响的 CXL.io 函数通知错误
2. 所有受影响的 CXL.io 功能都会在各自的 AER 扩展功能中记录 UIE/CIE
3. CXL.io 函数在标签 = 0 的链路上生成 PCIe ERR_ 消息
   4、DPA将ERR_消息转发给RCEC
4. RCEC 记录 UIE/CIE 并生成 MSI（如果根据 PCIe 基本规范启用）
   

12.2.2 CXL 2.0 Root Ports, Downstream Switch Ports, and Upstream Switch Ports（CXL 2.0 根端口、下游交换机端口和上游）

交换机端口 这些端口检测到的错误将使用 UIE/CIE 等 PCIe 错误报告机制进行升级和报告。
操作系统错误处理程序可以首先检查根端口 AER 扩展功能，并遵循 PCI Express 规则来发现错误源。 除了 PCI Express 基本规范和本规范中定义的错误日志之外，平台软件错误处理程序还可以询问平台特定的错误日志。

12.2.3 CXL Device Error Handling（CXL 设备错误处理）

每当 CXL 设备返回已知不良或可疑的数据时，它必须确保数据的使用者在使用时或使用数据之前了解数据的性质。 这允许消费者采取适当的遏制措施。
CXL 定义了两种遏制机制 - 中毒和病毒

1. 中毒：CXL.io 和 CXL.cachemem 上的返回数据可能被标记为中毒。
2. 病毒：CXL.cachemem 支持病毒，通常用于指示设备上更严重的错误情况。 请参阅<链接至病毒式传播部分>部分。 设备在与 Viral 通信后在 CXL.cachemem 上返回的任何数据都被视为可疑，即使它没有明确中毒。
   当元数据可疑时，设备必须在 CXL.cachemem 返回响应中将元字段设置为无操作。
   如果 CXL 组件不处于病毒状态，并且已知返回的数据是错误的或可疑的，那么它会毒害 CXL 接口上的所有数据响应。
   如果启用了 Viral，并且 CXL 组件处于 Viral 状态，建议该组件不要毒害 CXL.cachemem 接口上的后续数据响应，以避免错误污染。
   主机可能会将中毒数据发送到 CXL 连接的设备。 CXL 设备如何响应 Poison 是特定于设备的，但必须遵循 PCIe 准则。 设备必须有意识地决定如何处理有毒数据。 在某些情况下，简单地忽略中毒数据可能会导致 SDC（无声数据损坏）。 CXL 2.0
   设备需要以 64 字节粒度跟踪其接收到的任何有害数据。
   由于没有错误引脚，因此无法通过 Poison 指示处理的任何设备错误均应由设备以消息形式发送回主机。 为此，下面的表 224 显示了未实现内存错误记录和信令增强功能的设备的错误类型、其映射和错误报告指南的摘要（第 12.2.3.2 节）。
   对于实现内存错误记录和信号增强的器件，第 12.2.3.2 节描述了如何记录内存错误并用信号通知。 此类设备应遵循表 224 来处理所有非内存错误。
   
   Corrected (校正的):
   定义/例子：这是指可通过错误校正码（ECC）自动校正的内存单比特错误。即，该错误是可被检测并立即修复的，不会对系统的正常运行造成影响。
   Signaling Options (信号选项)：系统可以通过消息信号中断（MSI）或MSI-X（MSI的扩展版本，支持更多中断向量）来通知设备驱动程序发生了一个可校正的错误。
   Logging (记录)：设备特定的寄存器将包含有关该错误的信息，以便于将来检索和分析。
   Host HW/FW/SW Response (主机硬件/固件/软件响应)：设备驱动程序会有一个特定流程来处理这类校正的错误。
   Uncorrected Recoverable (未校正的可恢复的):
   定义/例子：指设备本身能够从中恢复的未校正错误，这种恢复对软件的帮助很少甚至不需要。例如，错误仅限于单个计算过程，不会影响到其他部分。
   Signaling Options (信号选项)：与可校正错误一样，系统会通过MSI或MSI-X来通知设备驱动程序发生了一个未校正但可恢复的错误。
   Logging (记录)：设备特定的寄存器也会记录此类错误的详细信息。
   Host HW/FW/SW Response (主机硬件/固件/软件响应)：与可校正错误相同，设备驱动程序会执行一个特定的处理流程来应对这种错误，例如丢弃可疑的计算结果。
   

12.2.3.1 CXL.mem and CXL.cache Errors（CXL.mem 和 CXL.cache 错误）

如果对内存的按需访问导致未纠正的数据错误，则 CXL 设备必须返回有毒数据。 请求者（处理器核心或对等设备）负责处理中毒指示。 CXL 设备不应随毒物一起发出未纠正的错误信号。 如果处理器核心消耗了毒药，
主机将记录错误并发出信号。
CXL 1.1 设备检测到的任何非需求未纠正错误（例如，CXL 设备内存控制器中的内存清理逻辑）将通过设备 MSI 或 MSI-X 向设备驱动程序发出信号。 任何更正的内存错误都将通过设备 MSI 或 MSI-X 发送给设备驱动程序。 驱动程序可能会选择重复分配内存页
错误。 平台固件和操作系统都不会直接处理这些错误。 CXL 1.1 设备可以实现第 12.2.3.2 节中描述的功能，在这种情况下不需要设备驱动程序。
如果 CXL 2.0 组件无法正确解码 CXL.mem 地址，则处理方法如第 8.2.5.12.2 节所述。 如果组件未实现 HDM 解码器（第 8.2.5.12 节），则它应丢弃此类写入事务并返回对此类读取事务的全 1 响应。

12.2.3.2 Memory Error Logging and Signaling Enhancements（ 内存错误记录和信令增强）

内存中的错误可能会在请求访问期间遇到，或者与向其发出的任何请求无关，并且记录有关此类错误的足够数据非常重要，以便能够使用主机平台级 RAS 功能，例如页面退役，而不依赖于 司机。
此外，与媒体完全无关的一般设备事件，包括设备健康状况的变化或设备检测到的环境条件，需要使用相同的一般事件记录工具来报告。
图 184 说明了一个用例，其中主机使用 CXL.mem 设备支持的两种信号发送方法（VDM 和 MSI/MSI-X）来实现固件优先和操作系统优先错误处理

支持内存错误记录和信令增强功能的 CXL 设备必须在本地记录此类错误，并通过 MMIO 邮箱将错误日志公开给系统软件（第 8.2.8.4.3 节）。 从邮箱中读取错误记录不会自动导致设备上的错误记录被删除。 需要显式清除操作才能从设备中删除错误记录。 为了支持错误记录访问和删除，设备应实现获取事件记录和清除事件记录命令。
两个操作都必须以原子方式执行。 此外，CXL.mem 设备对错误记录的所有写入或更新也必须以原子方式执行。
使用这两个操作，主机可以检索错误记录，如下所示：

1. 主机使用“获取事件记录”命令读取多个事件记录。
2. 完成后，主机使用“清除事件记录”命令清除设备中的事件记录，并提供一个或多个要清除的事件记录句柄。
   错误记录将归主机固件或操作系统所有，以便主机可以使用所有记录的错误来支持平台级 RAS 功能。
   存储在 CXL 设备上的错误记录必须在设备重置后保持粘性。 不得通过热重置或 FLR 或增强型 FLR 来初始化或修改记录。 当启用辅助电源消耗时，消耗辅助电源的设备必须保留错误记录。 在这些情况下，错误记录既不会被热、暖或冷重置初始化也不会被修改。

12.2.3.3 CXL Device Error Handling Flows（CXL 设备错误处理流程）

CXL 1.1 设备错误可能源自根端口 (RP) 或端点 (RCiEP)。 为了区分，RCiEP 源错误应使用零值标签，而 RP 源错误应使用非零值标签。 CXL 2.0 设备错误可能源自 CXL 2.0 端点 (EP)。 CXL 设备检测到的错误应通过 CXL.io 链路通过 PCIe 错误消息传达给主机。 与设备内任何特定功能无关且未通过 MSI/MSI-X 报告的错误将通过 PCIe 错误消息报告给主机，并可将其升级至平台。 UP 向所有记录非功能错误的 EP/RCiEP 报告这些错误。 每个 EP/RCiEP 通过 PCIe 错误消息向主机报告非功能特定错误。 软件应注意，即使 RCiEP 没有软件可见的链接，它仍可能记录与链接相关的错误。 对于多功能设备，最多生成一条给定严重性的错误消息。 错误消息必须包含能够发送错误消息的功能的请求者 ID。 对于具有相同严重性的不同错误，可以合并具有相同请求者 ID 的错误消息。 如果没有启用任何功能，则不会发送错误消息
所以。 如果启用不同功能发送不同严重程度的错误消息，则每个严重级别最多发送一个错误。 CXL 1.1 RCiEP 生成的错误将被发送到相应的 RCEC。 每个 RCiEP 必须与不超过一个 RCEC 关联。 CXL 2.0 组件生成的错误将记录在 CXL 2.0 根端口中。

12.3 CXL Link Down Handling（CXL 链路断开处理）

不存在优雅的 Link Down 的期望。 链路断开情况很可能会导致主机超时，因为很可能存在前往或来自 CXL 设备的事务最终无法取得进展。
软件可以配置 CXL 下游端口，以在出现某些类型的错误时触发下游端口遏制 (DPC)。 eDPC 可以在某些情况下实现可预测的遏制，但通常不会是可恢复的事件。

12.4 CXL Viral Handling（CXL 病毒处理）

CXL 链路和 CXL 设备预计符合 Viral 标准。 病毒式是一种错误遏制机制。 平台必须选择在启动时启用 Viral。 Viral 的主机实现允许平台通过写入寄存器来启用 Viral 功能。 类似地，写入设备上的 BIOS 可访问控制寄存器以启用
设备上的病毒行为（接收和发送）。 病毒支持能力和赋能控制都体现在 DVSEC 中。
启用后，只要检测到 Un Corrected_Fatal 错误，就会生成病毒指示。 Viral 不能替代现有的错误报告机制。 相反，其目的是提供额外的错误遏制机制。 错误检测器是负责通过 AER 报告错误并生成病毒指示。 任何能够报告 Un Corrected_Fatal 错误的实体也必须能够生成病毒指示。
CXL.mem 和 CXL.cache 采用病毒概念。 病毒式传播需要双向传播。 当启用病毒并且主机遇到病毒状况时，它应通过 CXL.mem 和/或 CXL.cache 将病毒通信到所有下游组件。 Viral 指示必须在可能受错误影响的任何数据之前到达（一般 Viral 要求）。 如果主机从任何 CXL 组件接收到病毒指示，它应将病毒传播到所有下游组件。
所有类型的常规重置均应清除病毒状况。 CXL 重置对病毒状况没有影响。 FLR 对病毒状况没有影响。

12.4.1 Switch Considerations（开关注意事项）

Viral 在每个 vPPB 的基础上启用，并且预期如果在一个或多个 DSP 上启用 Viral，那么它也将在 VCS 内的 USP 上启用。
在任何端口上收到的病毒指示会将 VCS 转换为病毒状态，但不会在交换机内触发新的未更正的致命错误。 一个 VCS 中的病毒指示不会影响交换机组件内的其他 VCS。 交换机继续处理所有针对该交换机的 CXL.io 流量并转发所有流量。 发送到 VCS 内所有端口的所有 CXL.cache 和 CXL.mem 流量均被视为已断言病毒位。 病毒指示应比任何后续 CXL.mem 或 CXL.cache 事务更快地从输入端口传播到 VCS 中的所有输出端口。 Viral 位在上游链路和连接到具有 Viral LD-ID 的 SLD 的链路上传播
矢量（参见表 54）设置为零以与 CXL 1.1 兼容。
如果交换机检测到未纠正的致命错误，则必须确定该错误是否影响一个或多个 VCS。 任何受影响的 VCS 都会进入病毒状态，设置 Viral_Status 位（请参阅第 8.1.3.3 节）以指示已发生病毒情况，在发送到 VCS 内所有端口的所有 CXL.cache 和 CXL.mem 流量中置位病毒位， 并发送 AER 消息。 受影响的 VCS 继续转发所有 CXL 流量。
DSP 以下设备的热移除和热添加不会影响交换机内 VCS 的病毒状态。
如果交换机已配置并启用 MLD 端口，则还有其他注意事项。 当具有 MLD 端口的 VCS 进入病毒状态时，它会通过设置该 VCS 中 LD 的病毒 LD-ID 向量（参见表 54）中的病毒位，将病毒指示传播到 MLD 组件内的 LD。 如果未纠正的致命错误导致一个或多个 VCS 进入病毒状态，则 LDVV 中的相应位
应设置。 已进入病毒状态的 MLD 组件内的 LD 使用 LDVV 掩码集设置 CXL.mem 流量中的病毒位，以识别与所有受影响的 VCS 关联的所有 LD-ID。 来自每个 LD-ID 的指示将病毒状态传播到启用了病毒遏制的所有关联 VCS。

12.4.2 Device Considerations（设备注意事项）

设备对 Viral 的反应将因设备而异，但预计设备会采取符合 Viral 要求的错误遏制措施。 首先，它必须防止不良数据被提交到永久存储。 如果设备连接到任何永久存储器或可能连接的外部接口
到永久存储，则设备需要自我隔离才能符合病毒标准。 这意味着设备必须在不依赖主机帮助的情况下采取遏制措施。
设备采取的遏制措施不得阻止主机前进。 这对于诊断目的以及避免错误污染非常重要（例如，将读取事务的数据保留到设备内存可能会导致主机中的级联超时）。 因此，在病毒检测方面，除了遏制要求外，设备还应：
• 删除对设备上或连接到设备的持久HDM 范围的写入。
• 必须始终返回完成响应。
• 在所有读取响应中将MetaField 设置为No-op。
• 当尝试将状态从“脏”更改为“干净”时，设置关闭状态命令（第 8.2.9.5.3.5 节中定义）因内部错误而失败。
• GPF 流量后不将关闭状态转换为“干净”。
• 将在收到病毒之前通过CXL 接口完成的任何写入提交到持久HDM 范围。
• 不断回应窥探。
• 完成对主机内存的挂起写入。
• 完成对设备易失性存储器的所有读取和写入。
当设备本身遇到病毒状况并且启用病毒时，它应：
• 设置病毒状态位以指示已发生病毒情况
• 遏制——采取措施将错误遏制在设备（或MLD 组件中的逻辑设备）内，并遵循上面列出的病毒遏制步骤。
• 将病毒状况备份CXL.mem 和CXL.cache 传送给主机。
— 病毒传播到虚拟层次结构中的所有设备，包括主机。
病毒控制和状态位在 DVSEC 中定义（详细信息请参见第 8.0 节“控制和状态寄存器”）。

12.5 CXL Error Injection（CXL 错误注入）

错误注入机制的主要目的是允许系统验证和系统固件/软件开发等创建错误场景和错误处理流程的手段。 为此，建议 CXL UP 和 DP 对指定地址（如果适用）实现以下错误注入挂钩：
• 一种类型的CXL.io UC 错误（可选- 类似于PCIe）。
— CXL.io 始终存在于任何 CXL 连接中
• 一种类型的 CXL.mem UC 错误（如果适用）
• 一种类型的 CXL.cache UC 错误（如果适用）
• 链接可纠正错误
— 瞬态模式和
— 持久模式
• 读取指定地址时返回Poison（仅限CXL.mem） 错误注入接口记录在合规性章节中。