ACPI 中文文档ACPI 中文文档
首页
第 1 章
第 2 章
第 3 章
第 4 章
第 5 章
第 6 章
第 7 章
第 8 章
第 9 章
第 10 章
第 11 章
第 12 章
第 13 章
第 14 章
第 15 章
第 16 章
第 17 章
第 18 章
第 19 章
第 20 章
第 21 章
附录 A
首页
第 1 章
第 2 章
第 3 章
第 4 章
第 5 章
第 6 章
第 7 章
第 8 章
第 9 章
第 10 章
第 11 章
第 12 章
第 13 章
第 14 章
第 15 章
第 16 章
第 17 章
第 18 章
第 19 章
第 20 章
第 21 章
附录 A
  • 第 18 章

    • 总览
    • 18.1. 硬件错误和错误源
    • 18.2. OSPM 与系统固件之间的关系
    • 18.3. 错误源发现
      • 18.3.1. 启动错误源
      • 18.3.2. ACPI 错误源
    • 18.4. 固件优先错误处理
    • 18.5. 错误串行化
    • 18.6. 错误注入
    • 18.7. GHES_ASSIST 错误报告

18.7. GHES_ASSIST 错误报告

在某些情况下,硬件报告的错误可能只提供有限的信息,因为附加信息可能需要平台特定的知识。因此,由给定 Error Source Structure 的 Flags 字段中的标记指示的 GHES_ASSIST 机制,允许系统固件在硬件报告的错误上下文中提供附加信息。具体来说,系统固件通过一个 Generic Hardware Error Source (GHES) 结构提供附加信息,该结构的 Related Source ID 指回表示该硬件的 Error Source 结构。OSPM 通过平台范围 _OSC Capabilities DWORD 2 的 GHES_ASSIST Support 标志来表明对 GHES_ASSIST 的支持。参见第 6.2.11.2 节,平台范围 OSPM 能力。

注

系统固件必须确保 GHES_ASSIST 结构提供的附加信息与硬件报告的当前错误状态信息保持一致。这意味着,当硬件生成错误时,系统固件必须具备在这些错误被传递给 OSPM 之前获得控制权的机制。

由于预期 OSPM 会在硬件报告的错误上下文中使用附加的 GHES_ASSIST 信息,因此,与相关 GHES 关联的通知结构应将 Type 字段设置为 轮询,或设置为与硬件错误事件信号方式一致的类型。参见 表 18.14、硬件错误通知结构。

OSPM 预期在使用完相关 GHES_ASSIST 结构中的任何附加信息后清除硬件错误状态。

18.7.1. 机器检查架构上的 GHES_ASSIST

为了在机器检查架构(MCA)错误源上支持 GHES_ASSIST,系统固件为每个 MCA 错误源提供一组 GHES 结构(参见 表 18.3 机器检查异常、表 18.5 已更正的机器检查,以及 表 18.15 延迟机器检查)。每组由每个逻辑处理器(CPU)上每个 MCA 硬件库组对应的一个 GHES 结构组成,并且每组中的 GHES 结构共享一个公共的 Related Source ID。

对于每个 MCA 错误源,OSPM 可以使用以下公式对这组 GHES_ASSIST 结构进行索引:

Index = ((CPU number) * (MCA Banks per CPU)) + (MCA Bank index)

其中,CPU number 表示 MADT 中相应的 Processor Local APIC 或 x2APIC 结构(Flags.Enabled = 1)的索引(例如,0 表示 MADT 中第一个已启用的 Processor Local APIC 或 x2APIC 条目),而 MCA Banks per CPU 表示相关 MCA 错误源结构中的 Number Of Hardware Banks 字段的值。

注

系统固件必须确保每组 GHES_ASSIST 结构在系统内存中按顺序布局,以便 OSPM 能够按照上述 Index 公式的说明使用它们。

Prev
18.6. 错误注入