blog
0%

RAS 调研

发表于 更新于 分类于 Valine：

RAS

RAS（Reliability、Availability and Serviceability），即可靠性、可用性、可维护性。

以下是 RAS 的三个主要目标:

  1. 提升系统可运行时间。
    RAS 技术可以提升服务器的可靠性，一般通过测量平均故障时间（MTTF）、年崩溃率（ACR）或年服务率（ASR）来度量。一个可靠的系统将保持运行更长的时间，因此更加可用。

  2. 减少非计划停机时间。
    当非计划停机出现时，可以通过测量平均修复时间 MTTR 来度量服务器的可维护性。一个可维护的系统可以快速恢复正常运行。
    硬件和固件协同支撑日志记录，帮助识别和隔离故障，让操作者可以进行预防性或主动性的维护。如果出现停机，可以快速地将系统重新上线，减少维护成本，并减轻停机对企业的后果。

  3. 维护数据完整性。
    RAS 技术提供了多种机制来防止数据损坏并纠正出错的数据。当检测到错误数据时，会确保它在可控制的范围内，避免引起更严重的问题。

x86 HPC ras 调研

错误分类

  • 可纠正错误 CE
    • 当检测到可纠正错误CE时，对错误位置进行标记，并通过对应模块的RAS技术快速修复错误，用户不会感知到这类错误的发生
  • 不可纠正错误 UCE
    • 尝试对故障进行隔离。比如通过隔离内存坏块、总线降频等手段，维持系统的运行。若发生了更为严重的故障，系统直接宕机，这时需要通过带外管理软件HDM恢复或重启系统
  • 硬件永久性故障
    • 需要更换新的硬件或者启用备用设备进行修复。通过对部分硬件的热插拔功能，可以支持用户在系统不断电的情况下，进行故障设备的更换，使服务器恢复正常工作。

故障上报

RAS 技术主要是通过 MCA 机制、AER 机制实现的 009

MCA

MCA (Machine Check Architecture) 机制可以上报并尽可能地修复系统总线、ECC、奇偶校验、缓存和 TLB 等等错误，识别故障源并将故障信息记录在 MC Bank 中。

MCA 是一个跟随着新处理器的发布不断增加新的特性和增强功能而不断进化的技术。

MCE (Machine Check Exception) 的产生通常是由于以下几个原因:

  1. 违反了主板设计指南，例如因为布线导致信号的干扰和完整性问题。
  2. 处理器工作在非正常的状态，比如超频等进而导致处理器出现意料之外的行为。
  3. 环境因素，比如环境太热，太冷，潮湿或者有辐射。
  4. 风扇或者散热器安装的有问题导致过热。
  5. 没有及时的升级 micorode，导致有些 fix 没有集成进来。
  6. BIOS 或者 OS 的配置有问题导致 MCE 的异常处理没有很好的工作。
  7. 板子上的设备如果外插卡，内存条等有问题也可能会导致 MCE。

在 MCA 架构的出现之前，OS 对 MCE 的处理非常有限，经常就是简单的重启系统
对于管理员而言，简单的系统重启难以接受，而且出错现场经常无法保存，从而无法排错。即使能够保留下一些日志，除非有很强的专业知识，否则完全不知道真正产生错误的原因是什么。

这些问题都在新的 MCA 中得到了解决和改进。利用新的 MCA 架构，CPU 可以按照配置产生 MCE(machine check exceptions)。
对于可以修正的（Correctable）MCE，硬件可以自动从错误状态中恢复，而且并不需要重启系统

早期的可修正的 MCE 并不需要产生中断，从 45nm Intel 64 处理器（CPUID 06H_1AH）开始引入了 corrected machine check error interrupt（CMCI）的机制，用户通过配置相应的 model-specific registers （MSR）允许可修正的 MCE 也会产生中断，软件可以捕捉到该中断并进行相应的处理。
对于不可修正的（uncorrectable）MCE，这时系统已经处于不再安全和可以信赖的操作模式，系统必须重启才能恢复。软件可以根据不同的错误源产生的错误类别，错误的严重程度，软件可以选择隔离错误，记录错误，甚至屏蔽错误源（对于不重要的非致命的错误类型）以避免干扰，或是必须要复位系统。
在新的 MCA 架构下，错误的记录管理，以及可读性都有了很大的提高。他可以

  • 帮助 CPU 设计人员和 CPU 调试人员诊断，隔离和了解处理器故障。
  • 帮助系统管理员检测在服务器长期运行期间遭受的短暂故障和与老化有关的故障。

MCA 恢复功能是基于 intel 至强可扩展系列处理器的服务器的容错功能的一部分。这些功能使系统在检测到未纠正的错误时可以继续运行。
如果没有这些功能，则系统将崩溃，并且可能需要更换硬件或重新引导系统。

通过 MCA 机制:

  • CPU 内部的可纠正错误和不可纠正错误均可上报并记录
  • 并纠正硬件可纠正错误。
  • 对于不可纠正错误，通常会进行热重启。
    MCA 的作用域包括处理器中的所有模块，Core、Uncore 和 IIO（通过 IOMCA）

AER

IIO AER (Integrated I/O Advanced Error Reporting) 机制 - PCI Express 的可选扩展功能
它提供了比标准 PCI Express 错误报告机制更强大的错误报告功能，包括 PCI Express AER、Traffic Switch、IRP、IIO 核心、英特尔 VT-D、CBDMA 和其他特定于英特尔的扩展。

负责侦测、记录并发送各种 IIO 模块下的子模块的错误信号，作用域包括 IIO 模块下的所有子模块，如 PCIe 接口，DMI，IIO 的核心逻辑和 Intel VT-d 等。

UPI

intel upi (Ultra Path Interconnect，极速通道互联)
UPI 可纠正错误上报：UPI 错误记录及信号发送的功能。

MCA 错误上报模式

处理器提供了以下几种不同的 MCA 错误上报模式： 010

  • Legacy IA-32 MCA 模式
    已经有几代英特尔处理器均支持 Legacy IA32 MCA 模式，该模式是大多数操作系统都支持的。
  • Corrupt Data Containmen 模式
    CDC（Corrupt Data Containment Mode）模式是对 MCA 机制的一种强化。当启动 CDC 模式并检测到不可纠正错误时，检测代理将设置“poison”位和数据一起转发给请求代理。
  • Enhanced MCA Gen1 (EMCA Gen1) Mode
    该模式是 Legacy IA-32 MCA 模式的第一代增强模式，是为了实现固件优先的错误报告模型。
  • Enhanced MCA Gen2 (EMCA Gen2) Mode
    第二代增强的 Legacy IA-32 MCA 模式。主要的目的是创建一个可通过操作系统启用的模式，并且进一步扩大固件第一模型（FFM）的错误报告范围。
  • IOMCA Mode
    允许 IIO 的不可纠正致命错误和不可纠正非致命错误通过 MCE 发送错误信号。

故障上报中断

011


错误处理流程

012

可纠正错误的处理 CE

如上图所示的橙色流程。

针对系统发生的可纠正错误，通过漏桶算法及设置可纠正错误阈值，可以实现在可纠正错误频繁发生时，触发 SMI (System Management Interrupt，系统管理中断) 中断通知 BIOS 进行错误处理，BIOS 接收到 SMI 中断请求后会根据不同的中断类型进行相对应的错误处理，在确保系统正常运行的同时，对发生错误的器件进行定位，隔离，搜集相关的错误状态寄存器信息，并上报 HDM 相关的错误事件及详细的错误状态寄存器信息，可供用户或服务器维护人员进一步分析问题发生原因。

不可纠正可恢复错误的处理 DE

如上图深绿色流程

对于不可纠正错误，如果这个错误是软件可恢复的（recoverable），则此错误并不会影响系统运行，只会将此错误数据将打上错误标记，并触发 SMI 中断，BIOS 收到此 SMI 中断后会搜集相关的错误寄存器信息，并对错误器件进行定位并上报 HDM 相关的错误信息及详细的错误状态寄存器信息。

不可纠正错误的处理 UE

如上图所示的黄褐色流程

如果 x86 系统发生了不可纠正且不可恢复的错误，CATERR_N 管脚会被拉低，这种错误会造成系统挂死，将会触发 HDM 的错误搜集程序，HDM 可以获取 x86 系统的错误状态寄存器信息，保证可以在系统挂死的情况下仍能在第一时间获取到错误现场信息，定位出错误根源并及时反馈给用户相关的信息。

错误日志记录

使用 MCA Bank、AER 状态寄存器、内存可纠正错误状态寄存器和 Intel UPI 错误状态寄存器实现 Core、Uncore 以及 IIO 模块的错误日志记录。

故障处理

内存故障处理


  • SDDC 提供错误检查和校正，用于校正 DIMM 上的单个 DRAM 颗粒故障（硬错误）和多比特故障。
  • ADDDC（MR），同样需要在 Virtual Lockstep 模式下启用，并且只支持可纠正区域。ADDDC 功能支持对于 x4 DDR4 的 DIMM，每个 IMC 纠正 2 个 DIMM 区域（Bank 或 Rank）

CPU 故障处理

当出现内核级错误，处理手段主要涉及到 Core Disable For Fault Resilient Boot 功能和 Core Corrupt Data Containment Enabled for DCU/IFU 功能。

  • Core Disable For FRB 功能 (Core Disable For Fault Resilient Boot)
    随着处理器内核数量的逐代增加，单个故障点从整个处理器转移到处理器内部的较小模块，比如单个 Core 或 LLC 的一部分。当出现了故障，除了可以禁用整个 CPU 之外，现在可以做到禁用特定的核。
    Core 的禁用需要保留至少一个 Core 是活动的，才能完成系统引导过程。
  • Core Corrupt Data Containment Enabled for DCU/IFU 功能
    处理器支持 DCU/IFU 的内核缺陷数据包容特性，在启用 MCA 恢复-执行路径的高级 RAS 特性的情况下，可以将某些类型的不可纠正数据错误上报为不可纠正可恢复错误（SRAR 类型的UCR）而非致命错误。
    “Error containment”位被一路传递给 DCU/IFU，从而允许隔离损坏的数据

PCIe 故障处理

  • PCIe Link Retraining and Recovery
    PCI Express 接口在出现链路降级时结合恢复机制，可以在不影响挂起的事务的情况下，进行重建链。如果在特定 lane 上出现了降级，恢复机制会按照 Platform Design Guide (PDG)定义的链路降级规则，降低链路宽度（例如，x16 链路将降级到 x8 链路）。如果在多个 lane 上出现降级，恢复算法会尝试在下一个允许的速度下重建链。
  • PCI Express Corrup Data Containment 功能（又称为 Data Poisoning）
    当接收端检测到不可纠正的数据错误时，使用“bad data”状态标识该错误数据，再将数据转发给目标，这种错误报告形式被称为“data poisoning”。接收 poison 数据的目标端，必须忽略数据，或者将数据带着“poison”标识存储起来。PCIE和一致性接口在事务分组中提供 poison 字段来标识错误数据。
    Data Poisoning 功能不仅限于发送的请求。需要用数据完成的请求也可以标识 poison 数据。

UPI 故障处理

  • Intel UPI Corrupt Data Containment (损坏数据抑制)
    • 当 UPI Date Poison 功能开启时
      Intel UPI 只是一个 poison 标识的管道。UPI TX/RX 接接收到 poison 数据，会继续将数据传送到目的地，并且不会触发错误信号或记录错误日志。这样将由数据的消费者来决定如何处理不可纠正的数据错误。
    • 当 UPI Date Poison 功能关闭时
      UPI 将看不到带有 poison 状态的数据，所有单元都返回到 Legacy MCA 模式，Intel UPI RX 收到 poison 数据，会发出一个错误信号并立即记录。
  • Intel UPI Dynamic Link Width Reduction
    在物理 lane 故障的情况下，支持从全带宽减小到 x8，半带宽支持仅用于 x8 位的最小集合，以允许任何单个数据通道失败。所得到的动态链路带宽减少模式是 lane[7:0]或[19:12]，就是说只要不是所有故障都在[7:0]和[19:12]上，多 lane 故障就可以被恢复。

RAS 系统架构 (新华三)

  • HDM：故障定位系统的核心，它负责故障的收集、汇总和分析，并通过 Web 管理界面事件日志以及故障告警等方式向客户呈现。
  • 处理器平台：服务器采用 Intel Skylake 至强 CPU 平台，该平台较上一代基础上增强了 RAS 的能力，增强了对处理器、内存、PCIe 设备硬件故障的管理能力。
  • CPLD (Complex Programmable Logic Device)：向下与各个硬件模块，包括电源、风扇以及其他底层硬件（除 CPU、内存、硬盘和 PCIe 标卡外）接口，捕获硬件异常状态，向上与 HDM 互连，传递故障信息。
  • BIOS：主要实现 CPU、内存、PCIe 以及存储设备的故障收集和定位，向 HDM 提供故障定位的结果，对 OS 层面来说，BIOS 提供 WHEA 等 OS 级故障管理的接口。
  • FIST（可选部件）：FIST 服务器配套管理软件。SDS 日志会记录服务器平台在每个使用周期过程中产生的从硬件到软件，从主 CPU 到 BIOS、OS 到 BMC 的大小事件。SDS 日志需通过 FIST 来解析。根据该功能查找服务器的使用记录或判断服务器的健康状况，客服或者工程师可以追寻服务器健康问题的蛛丝马迹，快速定位问题，从而提高服务器的可服务性。
  • IFIST（可选部件）：iFIST 是一款内嵌于服务器的单机管理工具，通过 iFIST 可以配置 RAID、安装操作系统、安装驱动程序和诊断服务器健康状况，以满足用户对单台服务器进行直接管理的需求。
  • 客户界面：主要通过 HDM 的 Web 界面，可以方便客户在远程或者本地进行系统维护工作，当然在主要部件上也会有故障指示灯。
  • 各类协议：故障管理系统中所用到的接口、协议包括：LPC，PECI，PCIe，UART，I2C，SMBUS，LocalBus 等。

RAS 功能表 (新华三)

RAS 功能一览表 016

RAS 功能简介

RAS 功能简介 019

riscv reri architecture

这个应该是类似于 X86 的 MCA

介绍

通过内存映射寄存器接口提供错误报告的标准机制，提供记录检测到的错误(包括其严重性、性质和位置)的功能，并配置了向 RAS 处理程序组件发送错误信号的方法。RAS 处理程序可以使用此信息来确定合适的恢复操作，这些操作可能包括:

  • 终止计算(例如，终止一个进程等)
  • 重新启动部分或全部系统等，以便从错误中恢复。

此外，该规范应支持软件发起的 RAS 处理程序的错误记录、报告和测试。
最后，该规范应提供实现错误处理的最大灵活性，并应与其他标准(如 PCle、CXL 等)定义的 RAS 框架共存。

错误级别

  • CE Corrected error. 同 x86 CE (可纠正错误)
  • UDE Uncorrected deferred error. 同 x86 DE (不可纠正可恢复错误)
  • UUE Uncorrected urgent error. 同 x84 UE (不可纠正错误)

feature

  • 标识错误严重等级和错误代码
  • 内存映射的错误记录寄存器, 错误记录 bank
  • 规则- 高优先级的错误记录可以覆盖低优先级的错误记录 (UUE > UDE > CE)
  • 可纠正错误 (CE) 计数
  • RAS handler 用于测试的错误注入机制

错误上报

主体:

  • riscv hart
  • 内存控制器

可支持一个或多个错误记录 bank
每个错误记录对应于组件的一个硬件单元，并报告由该硬件单元检测到的错误。
一个硬件单元可以实现多个错误记录。
由于组件中的一个或多个硬件单元检测到错误，或由于一个硬件单元检测到一个或多个错误，所以同一时间有一个或多个错误记录是有效的.

寄存器

每个错误记录对应一组寄存器，用于控制该错误记录，报告状态、地址和其他与该错误记录中的错误有关的信息

比较重要的 csr:

  • Error bank information (bank_info)

    系统的供应商将 inst_id 定义为组件的唯一标识符。返回值为 0 表示该字段未实现。
    N_err_recs 字段表示错误记录的数量。

  • Summary of valid error records (valid_summary)

    • sv=1 时, 软件通过 valid_bitmap 确定 bank 中的哪条错误记录是有效的, 哪条有效, 就说明哪组 i csr 是有效的. i 表示第 i 个错误记录的 index.
      一条错误记录有一组 csr , 由 status_i, control_i, info_i, addr_i 等组成.
    • sv=0 时, 软件需要遍历 status_i.v 来确定 error 记录是否有效.

  • Status register (status_i)
    The status_i is a read-write WARL register that reports errors detected by the hardware unit

    • v = 1 代表该条错误记录有效
    • ce 为 1, 代表该错误记录为可纠正错误
    • de 为 1, 代表该错误记录为不可纠正可恢复错误
    • ue 为 1, 代表该条错误记录为不可纠正验证错误
    • at 代表该条错误记录所涉及的地址是 VA/HPA/GPA 中的哪个
    • c 为 1, 表示错误可能是可控的，但 RAS 处理程序可能能够也可能无法从此类错误中恢复系统。RAS 处理程序必须根据错误记录中提供的附加信息(如检测到损坏的内存地址等)做出恢复决定。
    • pri 代表该条错误记录在该类错误中的优先级. 数越大优先级越高
    • mo 为 1, 代表相同类型的错误已发生过多次
    • tt 代表导致该错误记录时的访问类型, 有隐式/显式读/写等
    • iv=1 代表该条错误记录携带了额外信息, 额外信息被写入到 info_i 中.
    • siv=1 代表该条错误记录携带了额外补充信息, 额外补充信息被写入到 suppl_info_i 中.
    • tsv=1 代表该条错误记录携带了时间戳, 时间戳写入到 timestamp_i 中
    • scrub=1 代表该条错误记录为 CE, 且地址上的错误数据已经被纠正.
    • ec (error code), 代表该条错误记录的错误识别代码

    • cec (corrected-Error-counter), 当 control_i.cece=1 时, cec 代表当前已发生 CE 的错误记录的总计数.

  • Control register (control_i)

    Control_i 是一个读/写 WARL 寄存器，用于控制错误库中相应错误记录的错误报告。
    The ces, udes, and uues are WARL fields used to enable signaling of CE, UDE, and UUE respectively When they are logged.

    • control_i.sinv 清除 status_i 的 v 位.
    • else = 1, 记录错误记录的错误上报功能启用. =0, 关闭, 关闭时 CE 错误的硬件纠错机制仍然是开的, 建议在关闭时硬件组件继续对由硬件组件产生或存储的数据产生错误进行检测和纠正. 建议在关闭的情况下仍然抑制病毒数据
    • ces/udes/uues 分别控制 CE/UDE/UUE 错误的错误上报.

      错误记录产生的信号除了引起中断/事件通知外，还可以用来携带额外的信息，以帮助平台中的 RAS 处理程序.
      错误信号可以通过平台特定的方式配置中断类型, 通知平台中的 RAS 处理程序。例如，高优先级的 RAS 信号可被配置为引起高优先级的 RAS 本地中断、外部中断或 NMI，低优先级的 RAS 信号可被配置为引起低优先级的 RAS 本地中断或外部中断。
    • cece = 1, 打开 status_i.cec (CE 错误计数)
    • eid (error-injection-delay), 错误注入延时. 前面讲了错误注入机制是为了测试目的. eid 中有值时, 开始以特定的频率向下递减, 当 eid 达到 0 时, 产生一条错误记录, 错误记录就是对应 status_i 中的错误记录, 在错误上报开关打开后, 会产生对应的中断通知 RAS 处理程序.
      只会产生错误记录, 并不会产生错误反映到硬件上, 因此不是用来验证硬件错误的.
      软件应确保该机制不会被滥用而产生安全问题.

  • Address register (addr_i)
    The addr_i WARL register reports the address associated with the detected error

  • Information register (info_i)
    The info_i WARL register provides additional information about the error when status_i.iv is 1
    此字段结合 status_i.ec 错误代码看, 可用于报告特定于错误的信息，以帮助定位失败的组件、指导恢复操作、确定错误是暂时的还是永久的，等等。该字段可用于报告有关组件中错误位置的更详细信息，例如，检测错误的集合和方式、出错的奇偶校验组、ECC 错误状态、协议 FSM 状态、导致断言失败的输入等。

  • Supplemental information register (suppl_info_i)
    与 status_i.ec 结合, 代表特定的信息.

riscv ras 硬件方案 (develop simple)

https://riscv-europe.org/media/proceedings/posters/2023-06-06-Daniele-ROSSI-abstract.pdf

  • Error Mux
    多路错误接收复用器, 接收硬件错误信号, 根据硬件错误信号生成错误消息 (包括错误识别代码, 错误类型等), 将错误消息存放到 FIFO Buffer 中.

  • DE Controller 处理不可纠正可恢复错误。
    为了执行它的任务，读/写信号也是必需的。实际上，如果在读取操作期间访问了存储带有 DE 的数据的内存位置，那么这些有毒的数据将被消耗掉。因此，需要将 DE 升级为紧急错误 UE。相反，跟踪一个写操作到一个有延迟错误的位置，允许我们使相应的错误记录无效，因为在这种情况下，旧的数据将被新的数据覆盖。

  • Main controller
    用于选择用于定位错误记录的寄存器组, 采用了一种全组相连的 cache 缓存策略, 在错误产生时, 它会找到空闲的 bank (即确定 bank csr 组的 index), 将该错误记录存到该组寄存器下.
    如果所有错误记录都被占用了 (没有空闲的), 由它选择丢弃新的错误记录, 或者按照优先级将新的错误记录覆盖掉旧的. 优先级的顺序 UE>DE>CE, 对应其中每个子类别, 会按照 status_i.pri 来排序.

  • FIFO Buffer, 缓存来自 Error Mux 的错误记录消息

  • Error Record Banks
    即对应 Feature Register, 即前面介绍的 riscv reri architecture 中的所有的寄存器. 这些 csr 是 memory-mapped. 应该不在 cpu 内部, 而在 soc 范围, 设计时需要符合 riscv reri architecture 规范.

  • IRQ Gen 单元
    负责在不同场景中产生中断信号, 需要根据 riscv 寄存器组中 control_i 的设定来判断是否要生成中断信号. 不同的错误生成不同的中断 (根据错误级别可配置本地中断、外部中断或 NMI)

Linux

Documentation/admin-guide/ras. Rst
主要是 EDAC (Error Detection And Correction)
包括两个子系统，

  • Edac_mc
    负责收集内存控制器报告的错误
  • Edac_device。
    负责其他控制器（比如 L3 Cache 控制器）报告的错误。
    通常是把控制器的驱动写成一个 platform device，然后在 probe 的时候注册为 edac_mc 或者 edac_device。
1
2
3
4
edac_mc_handle_error()
edac_raw_mc_handle_error()
edac_device_handle_ce()
edac_device_handle_ue()

这些报告函数主要干这些事：

  1. Printk：把错误打印到 print ring buffer 里面
  2. Trace_mc_event：把错误写到 ftrace 的一个跟踪项中
  3. 统计：把这个错误报告到根据 DIMM 条，Rank，Row 的分类进行统计，为后续进行硬件替换提供参考
  4. 如果硬件报这是个 UE，而且这个控制器要求 UE 即停机，则复位系统

Printk 是个参考，是不适合正式处理的
Trace_xxx 是个跟踪，不开跟踪就不能工作，统计不能用于单个处理。

所以，当我们给 Linux 实现 RAS 特性的（硬件的）时候，必须有意识地用 page_fault 一类的异常来控制传播范围，只把中断的报告看作是统计上的补充。

当硬件侦测到一个错误，它有两种方法报告 CPU:

  • 一种方法是中断。这是个异步的过程，很容易造成传播范围不可控。

    • 如果这是 CE 的，错误已经被硬件主动修复，或者可以有手段修复（比如通过产生同步异常）。
    • 是 UE 的，这基本上就要导致停机乃至整体隔离了。

  • 第二种错误的报告方法是把错误随着 CPU 核的读写响应（消息）返回给 CPU，让 CPU 产生一个同步异常

    • 这种异常体现在 CPU 核上，就是一个 page_fault 中断，只是不同的类型，CPU 可以通过给对应的进程发 SIGBUS 一类的信号来控制这个错误。

Bios uefi

ACPI APEI 表

EDAC 是比较原始的实现，需要为每个平台的控制器写独立的驱动。ACPI 标准的 APEI 表从 BIOS 层提供了标准的报告形式。APEI 是 ACPI Platform Error Interface 的缩写，它包括多张表：

  1. BERT: Boot Error Record Table，这个用于记录前一次复位前 BIOS 记下来的错误，Linux 读到这个记录会打印出来，以便知道比如上次因为 UE 而服务的原因
  2. EINJ：Error INJection，BIOS 提供的硬件故障注入的接口，Linux 把这个封装成 debugfs 的属性了，可以通过这个注入需要的硬件错误
  3. ERST：Error Record Serialization Table，这个表用于配合 BERT，从 OS 侧辅助 BIOS 把临时前的错误信息保存到持久设备中。做硬件的同学要考虑适配这套框架，保证错误可以被固化到持久的存储中
  4. HEST: Hardware Error Source Table，这个描述系统有多少个错误检测设备，Linux 中这个被实现为多个（每条记录一个）平台设备
  5. GHES：General Hardware Error Source，这是硬件报错的接口。Linux 中，这个被实现为 HEST 定义的设备的驱动，每个那样的平台设备，Probe 到这个驱动上后，再注册为一个 edac_mc 设备，这样就和 EDAC 框架结合起来了

从这里可以看到，APEI 一定程度上是基于 EDAC 框架的，但它同时也提供独立于 EDAC 之外的功能。所以，高级的标准的服务器，更应该选择的是走 APEI 路线，而不是 EDAC 的路线。

只要硬件提供 APEI 接口，Linux 上就不需要额外的驱动了。

异常内存页隔离

如果我们发现异常的内存问题:

  • 一种办法当然可以立即停机。
  • 还有一种方法是隔离掉这片内存。
    这个功能依然做在 GHES 上，ghes_handle_memory_failure() 调用 mm/mm-failure.c 中的异常函数，Linux 会把这个 page 标记为 HWPOISON 的，之后相关的页，VM 或者进程就会被隔离掉。

不能避免错误被传播出去。但对一般数据中心来说，可能也够了。对大部分数据中心来说，你能说你这个节点不可信就够了，本来也不指望你还能提供内存双备这种不计成本的高级特性来。

Reference

AMD64 Architecture Programmer’s Manual, Volume 2: System Programming
Intel Xeon Processor E7 Family: Reliability, Availability, and Serviceability - White paper
Arm® Reliability, Availability, and Serviceability (RAS) Specification - Armv8 Architecture Profile, July 2019.
RERI (RAS Error-record Register Interface) task group. URL:https://lists.riscv.org/g/tech-ras-eri.