18.3.2. ACPI 错误源

硬件错误源描述了一种标准化机制，平台可使用该机制来描述其错误源。使用此接口是平台描述其错误源的首选方式，因为它独立于平台和处理器体系结构，并允许平台描述与错误源相关的运行参数。

此机制允许平台详细描述错误源；在必要时向 OSPM 传达运行参数（即严重性级别、屏蔽位和阈值）。它还允许平台报告那些 OSPM 通常不会实现支持的错误源（例如，芯片组特定错误寄存器）。

硬件错误源表 (HEST) 为平台固件提供了一种向 OSPM 描述系统硬件错误源的方法。HEST 格式如下表所示。

表 18.2 硬件错误源表 (HEST)

| 40 | 一系列错误源描述符项。

注

错误源类型 3、4 和 5 由于遗留原因被保留，且不得使用。

以下各节详细说明了每一种特定的错误源描述符。

18.3.2.1. IA-32 体系结构机器检查异常

实现 IA-32 指令集体系结构的处理器采用机器检查异常机制，以向 OSPM 警示存在未纠正的硬件错误条件。此表中的信息由 OSPM 用于为系统中的每个处理器配置机器检查异常机制。

HEST 中只允许一个此类型的项。OSPM 将此项中指定的信息应用于所有处理器。

表 18.3 IA-32 体系结构机器检查异常结构

| 40 | 由 IA-32 架构机器检查 Bank 结构 定义的机器检查 Bank 结构列表

18.3.2.1.1. IA-32 架构机器检查 Bank 结构

此表描述特定 IA-32 架构机器检查硬件错误库的属性。

表 18.4 IA-32 架构机器检查错误库结构

18.3.2.2. IA-32 架构已更正机器检查

实现 IA-32 指令集架构的处理器可以向 OSPM 报告已更正的处理器错误。此表中的信息使平台固件能够向 OSPM 传达已更正处理器错误报告机制的关键参数，包括是否应启用 CMC 处理。

HEST 中仅允许有一个此类型的条目。OSPM 将此条目中指定的信息应用于所有处理器。

表 18.5 IA-32 架构已更正机器检查结构

| 48 | 在 IA-32 架构机器检查 Bank 结构 中定义的机器检查 Bank 结构列表。

18.3.2.3. IA-32 架构不可屏蔽中断

未更正的平台错误通常使用不可屏蔽中断（NMI）向量（例如，INT 2）进行报告。此表允许平台固件传达有关 NMI 错误条件的配置和处理参数。

HEST 中仅允许有一个此类型的条目。

表 18.6 IA-32 架构 NMI 错误结构

18.3.2.4. PCI Express Root Port AER 结构

PCI Express（PCIe）Root Port 可以实现 PCIe 高级错误报告（AER）支持。此表包含平台固件为在给定 Root Port 上配置 AER 支持而提供给 OSPM 的信息。

如果所有条目中都没有设置 GLOBAL 标志，则 HEST 可为每个 PCI Express Root Port 包含一个此类型的条目。如果设置了 GLOBAL 标志，则只能有一个此类型的条目，并且该条目中包含的信息将应用于所有 PCIe Root Port。

表 18.7 PCI Express Root Port AER 结构

注意

对于 PCI Express 高级错误报告（AER）资源，AER 寄存器的所有权和控制由对 PCI _OSC() 方法的求值来确定，如 PCI Firmware Specification 的最新修订版中所述。标志字段中的 FIRMWARE_FIRST 位不用于授予或拒绝对该结构所描述的 PCI Express 设备中的 AER 寄存器的访问。

18.3.2.5. PCI Express Device AER 结构

PCI Express 设备可以实现 AER 支持。此表包含平台固件为在给定 PCI Express 设备上配置 AER 支持而提供给 OSPM 的信息。

如果所有条目中都没有设置 GLOBAL 标志，则 HEST 可为每个 PCI Express 端点设备包含一个此类型的条目。如果设置了 GLOBAL 标志，则只能有一个此类型的条目，并且该条目中包含的信息将应用于所有 PCI Express 端点设备。

表 18.8 PCI Express Device AER 结构

注

对于 PCI Express 高级错误报告（AER）资源，AER 寄存器的所有权和控制由对 PCI _OSC() 方法的求值来确定，如 PCI 固件规范的最新修订版所述。Flags 字段中的 FIRMWARE_FIRST 位并不用于授予或拒绝对结构所描述的 PCI Express 设备中的 AER 寄存器的访问。

18.3.2.6. PCI Express/PCI-X 桥 AER 结构

实现 AER 支持的 PCI Express/PCI-X 桥实现了用于控制错误如何跨桥报告的字段。

如果所有条目中都没有设置 GLOBAL 标志，则 HEST 可以为每个 PCI Express/PCI-X 桥包含一个此类型的条目。如果设置了 GLOBAL 标志，则此类型只能有一个条目，并且该条目中包含的信息将应用于所有 PCI Express/ PCI-X 桥。

表 18.9 PCI Express/PCI-X 桥 AER 结构

注

对于 PCI Express 高级错误报告（AER）资源，AER 寄存器的所有权和控制由对 PCI _OSC() 方法的求值来确定，如 PCI 固件规范的最新修订版所述。Flags 字段中的 FIRMWARE_FIRST 位并不用于授予或拒绝对结构所描述的 PCI Express 设备中的 AER 寄存器的访问。

18.3.2.7. 通用硬件错误源

平台可以使用通用硬件错误源结构向 OSPM 描述一个通用硬件错误源。通用硬件错误源是指使用非标准通知机制向 OSPM 通知错误存在，或者报告以非标准格式编码的错误信息的错误源。

使用通用硬件错误源结构中的信息，OSPM 配置错误处理程序，从错误状态块读取错误数据——这是平台预留用于记录错误状态信息的一段内存范围。

由于通用硬件错误源是非标准的，OSPM 不实现用于配置和控制操作的内建支持。该错误源必须由系统固件在启动期间进行配置。

某些平台可能会描述具有不同通知类型的多个通用硬件错误源结构，如表 18.10 所定义。例如，平台可以描述一个用于处理同步错误（例如 MCE 或 SEA）的错误源，以及第二个用于处理异步错误（例如 SCI 或 External Interrupt）的错误源。

表 18.10 通用硬件错误源结构

错误状态地址字段指定一个 8 字节内存映射寄存器的位置，该寄存器保存错误状态块的物理地址。该错误状态块必须位于向 OSPM 报告为固件保留的一段内存范围中。OSPM 将错误状态缓冲区映射到系统地址空间中，以便读取错误数据。

18.3.2.7.1. 通用错误数据

错误状态块包含给定通用错误源的错误状态信息。OSPM 提供一个错误处理程序，根据特定操作系统的需要，将一个或多个此类块格式化。

通用错误状态块包括两级信息。顶层是下表定义的 Generic Error Status Block 结构。下一层是一个或多个 Generic Error Data Entry 结构，定义见下方第二个表。

表 18.11 通用错误状态块

可以在 Generic Error Status Block 结构的 Generic Error Data Entries 字段中记录一个或多个通用错误数据项结构。这使平台能够为与给定错误事件相关的多个硬件组件累积信息。例如，如果通用错误源表示发生在 PCI Express / PCI-X Bridge 次级侧某设备上的错误，则记录来自 PCI Express Bridge 和 PCI-X 设备的错误信息会很有用。利用两个通用错误数据项结构即可实现这一点——见下文表 18.12。

有关下表所描述字段的更多细节，请参见 UEFI Specification 附录中“通用平台错误记录”的节描述符定义。

表 18.12 通用错误数据项

18.3.2.7.2. 用于通用错误源的事件通知

对于已校正错误，建议使用事件通知，因为处理错误报告的延迟对于系统正常运行并不关键。事件通知的实现要求平台在 ACPI 命名空间中定义一个 PNP ID 为 PNP0C33 的设备，称为错误设备。该设备用于通知 OSPM 某个通用错误源正在报告错误。由于多个通用错误源都可以使用事件通知，因此 OSPM 有责任扫描这些通用错误源的列表，并检查块状态字段（Generic Error Status Block），以识别报告错误的源。

平台负责提供一个控制方法，该方法对错误设备（PNP0C33）发出 NOTIFY，通知代码类型为 0x80。

对于传统 ACPI 平台，事件信号遵循将匹配的控制方法排队执行中描述的模型。平台为错误通知实现一个通用事件（GPE），并且该 GPE 具有关联的控制方法。

错误通知的 GPE 控制方法示例如下：

Method (\_GPE._L08) { // GPE 8 level error notification
  Notify (error_device, 0x80)
}

对于 HW-reduced ACPI 平台，事件信号遵循GPIO 发信号的 ACPI 事件和中断发信号的 ACPI 事件中描述的模型。平台通过中断或 GPIO 引脚实现错误事件通知。在这两种情况下，它们都与一个 _EVT 控制方法相关联。

基于 GPIO 的错误通知的 _EVT 控制方法示例如下：

Method (\_EVT) { // GPIO pin 300 error notification
  Switch (Arg1) {
    Case (300) {
      Notify (error_device, 0x80)
    }
  }
}

当平台使用事件通知时，整体流程如下：

• 平台使用 Generic Hardware Error Source Structure 和 Generic Error Status Block 中的格式，将带有事件作为通知方法的错误源进行枚举。

• 平台向 OSPM 提供一个错误设备，PNP ID 为 PNP0C33

• 当平台准备报告错误时，平台填充错误状态块，包括块状态字段（Generic Error Status Block）。

传统 ACPI 平台使用 SCI 在适当的 GPE 上发出错误信号：

• OSPM 按照将匹配的控制方法排队执行中的说明，求值与该事件关联的 GPE 控制方法

• OSPM 通过检查所有使用 SCI 通用通知类型的通用错误源的错误状态块，来识别报告该错误的源，并响应此通知

硬件精简 ACPI 平台使用 GPIO 中断或在通用事件设备下声明的其他中断发出错误信号（中断发信号的 ACPI 事件）。对于 GPIO 发信号事件，由 _AEI 对象列出相应的 GPIO 引脚；对于中断发信号事件，则使用 _CRS 对象列出中断：

• OSPM 按照处理 GPIO 发信号事件的事件方法和处理中断发信号事件的事件方法中的说明，求值与该事件关联的控制方法。

• OSPM 通过检查所有使用 GPIO 发信号通知或中断发信号通知类型的通用错误源的错误状态块，来识别报告该错误的源，并响应此通知。

18.3.2.8. 通用硬件错误源版本 2（GHESv2 - Type 10）

这是对 Generic Hardware Error source 结构（第 18.3.2.7 节）的扩展，用于依赖 RAS 控制器生成通用错误记录的硬件精简平台。RAS 控制器可以是硬件实体或固件实体，并且可以与 OS 并行执行（例如，RAS 控制器可以是在独立微控制器上运行的固件，或者也可以是运行在某个应用处理器上的平台固件）。具有 RAS 控制器的平台必须防止对 Error Status Block 的并发访问（即，在 OS 完成读取之前，RAS 控制器不得覆盖 Error Status Block）。下表提供了 RAS 控制器可能如何与 OS 交互的高级示例。

图 18.1 带外部 RAS 控制器的 APEI 错误流示例

对于 GHESv2 错误源，OSPM 必须通过写入 GHESv2 结构中列出的“Read Ack Register”来确认已使用 Error Status Block（如下表所述）。对于描述多个 Generic Hardware Error Source 的平台，平台必须为每个错误源的 Error Status Block 提供唯一的内存区域。

表 18.13 通用硬件错误源版本 2（GHESv2）结构

一旦从特定 GHESv2 错误源检测到错误，OS 必须执行以下步骤：

• OSPM 检测到错误（通过中断/异常或轮询块状态）

• OSPM 复制错误状态块

• OSPM 清除错误状态块的块状态字段

• OSPM 通过 Read Ack register 确认该错误。例如：

  • OSPM 读取 Read Ack register –> X

  • OSPM 写入 –> (( X & ReadAckPreserve) | ReadAckWrite)

18.3.2.9. 硬件错误通知

此表描述了与硬件错误源关联的通知机制。

表 18.14 硬件错误通知结构

18.3.2.10. IA-32 架构延迟机器检查

实现 IA-32 指令集架构的处理器可以向 OSPM 报告延迟错误。这些错误表明数据已损坏但尚未被使用。此表中的信息使平台固件能够向 OSPM 传达延迟处理器错误报告机制的关键参数，包括是否应启用延迟机器检查（DMC）处理。

HEST 中仅允许有一个此类型的条目。OSPM 将此条目中指定的信息应用于所有处理器。

表 18.15 IA-32 架构延迟机器检查结构

| 48 | IA-32 架构机器检查库结构 中定义的 Machine Check Bank 结构列表。