ACPI表定制开发实战 - 第1节
1.1 ACPI 的起源与发展
ACPI（Advanced Configuration and Power Interface，高级配置与电源接口）是操作系统与硬件平台之间进行电源管理、设备配置和热管理的开放标准。它的诞生源于早期 PC 平台电源管理方案的碎片化与局限性。
1.1.1 前 ACPI 时代的电源管理
在 ACPI 出现之前，PC 平台主要依赖以下两种电源管理方案：
| 方案 | 控制方 | 核心问题 |
|---|---|---|
| APM（高级电源管理） | BIOS（固件） | 操作系统对电源状态无感知，BIOS 定时器轮询导致响应延迟；不支持热插拔和动态设备配置 |
| PNP（即插即用 BIOS） | BIOS + 操作系统 | 资源分配由 BIOS 静态完成，操作系统无法动态调整；中断/IO 冲突难以解决 |
这两种方案的共同缺陷是：操作系统被排除在电源与配置决策之外。BIOS 作为固件层，无法感知上层应用的负载变化，导致电源管理粗放、响应迟钝。
1.1.2 ACPI 的诞生与演进
1996 年，Intel、Microsoft、Toshiba 联合发布 ACPI 1.0 规范，首次将电源管理和设备配置的主导权从 BIOS 移交到操作系统。此后 ACPI 规范持续演进：
- ACPI 1.0（1996）：定义基础电源状态（S1-S5）、设备电源状态（D0-D3）、处理器性能状态（P-states）。
- ACPI 2.0（2000）：引入 64 位寻址支持、热插拔扩展、ACPI 命名空间（Namespace）标准化。
- ACPI 3.0（2004）：增加处理器节流（T-states）、内存映射配置、扩展热区模型。
- ACPI 4.0（2009）：引入系统进入/退出延迟描述、USB 3.0 电源管理、虚拟化支持。
- ACPI 5.0（2011）：面向 ARM 架构扩展，增加硬件减固件接口（HEST/ERST）、UEFI 启动支持。
- ACPI 6.0+（2015-至今）：持续完善异构计算、CXL（Compute Express Link）、CCEL（平台固件运行时数据）等新硬件模型。
1.2 ACPI 在现代操作系统中的作用
ACPI 是现代操作系统（Windows、Linux、macOS）与硬件平台之间的契约层。操作系统通过 ACPI 获取硬件拓扑、电源能力、热约束等信息，并据此做出运行时决策。
1.2.1 核心功能矩阵
| 功能域 | ACPI 机制 | 操作系统行为 |
|---|---|---|
| 电源状态管理 | 全局状态（G0-G3）、睡眠状态（S0-S5） | 根据用户策略和空闲检测，触发系统进入低功耗状态 |
| 设备电源管理 | 设备电源状态（D0-D3cold）、_PS0/_PS3 控制方法 |
动态关闭空闲设备，降低整机功耗 |
| 处理器性能管理 | P-states（性能状态）、C-states（空闲状态）、T-states（节流状态） | 根据 CPU 负载和散热约束，动态调频调压 |
| 热管理 | 热区（Thermal Zone）、_TMP/_ACx/_PSV 控制方法 |
监测温度，触发风扇调速、降频或系统关机 |
| 设备枚举与配置 | ACPI 命名空间、_HID/_CID/_ADR 对象 |
操作系统遍历命名空间，加载对应驱动并分配资源 |
| 热插拔 | _EJ0/_STA/_DCK 控制方法 |
支持 PCIe、USB、NVMe 等设备的热插拔事件处理 |
1.2.2 操作系统如何消费 ACPI 表
操作系统在启动阶段通过 UEFI 或 BIOS 加载 ACPI 表（RSDP → RSDT/XSDT → 各子表），然后解析命名空间并执行控制方法（AML 字节码）。整个过程可概括为：
- 定位根表：操作系统在 UEFI 配置表或 BIOS 内存区域查找 RSDP（Root System Description Pointer）。
- 解析表结构：通过 RSDT/XSDT 找到 DSDT（Differentiated System Description Table）和 SSDT（Secondary System Description Table）。
- 加载命名空间：将 DSDT/SSDT 中的设备对象和控制方法加载到 ACPI 命名空间树中。
- 执行控制方法：操作系统在需要时（如设备初始化、电源状态切换）调用 AML 解释器执行对应控制方法。
- 响应事件：硬件触发 SCI（System Control Interrupt），操作系统通过 ACPI 事件模型处理热插拔、温度变化等异步事件。
_DSM 方法让操作系统识别自定义硬件功能。
1.3 ACPI 与 BIOS/UEFI 的关系
ACPI 既不是 BIOS 的替代品，也不是 UEFI 的组成部分，而是独立于固件类型的硬件抽象层。BIOS/UEFI 负责在启动阶段加载 ACPI 表，而 ACPI 表本身定义了操作系统与硬件的交互契约。
1.3.1 三者的职责边界
| 层次 | 典型实现 | 核心职责 | 与 ACPI 的关系 |
|---|---|---|---|
| 固件（BIOS/UEFI） | AMI BIOS、EDK II、TianoCore | 硬件初始化、启动引导、运行时服务 | 在启动阶段构建并安装 ACPI 表到内存；提供 ACPI 运行时接口（如 SMM 回调） |
| ACPI 层 | DSDT/SSDT 表、AML 字节码 | 定义硬件拓扑、电源/热/配置策略 | 独立于固件类型，由操作系统解释执行 |
| 操作系统 | Windows ACPI 驱动、Linux ACPI 子系统 | 解析 ACPI 表、执行控制方法、管理电源/设备 | 消费 ACPI 表，不直接依赖固件实现 |
1.3.2 启动阶段的协作流程
下图展示了从系统上电到操作系统接管 ACPI 表的完整流程：
1.3.3 固件与 ACPI 的运行时交互
除了启动阶段的表加载，BIOS/UEFI 在运行时也通过以下机制与 ACPI 协作：
- SMM（系统管理模式）回调：ACPI 控制方法可以通过
_OSC（操作系统能力协商）触发 SMM 中断，让固件执行特权操作（如设置硬件寄存器）。 - UEFI 运行时服务：UEFI 固件提供
GetVariable/SetVariable等运行时服务，ACPI 表可以通过NVS（非易失性存储）区域与固件共享数据。 - ACPI 事件模型：硬件事件（如温度超限、电池状态变化）通过 GPE（General Purpose Event）触发 SCI，固件在 SMM 中处理事件或直接转发给操作系统。
1.4 本章小结
ACPI 从 1996 年发展至今，已成为现代操作系统与硬件平台之间的核心契约层。它解决了前 ACPI 时代电源管理碎片化的问题，将配置与电源决策权从 BIOS 移交到操作系统。ACPI 表由 BIOS/UEFI 在启动阶段构建并安装到内存，操作系统在运行时解析和执行这些表，从而实现电源管理、设备配置、热管理等关键功能。理解 ACPI 的起源、作用及其与固件的关系，是后续进行 ACPI 表定制开发的基础。