ACPI规范概览
1 Overview
背景
ACPI是在1990s由英特尔、微软、东芝、惠普和凤凰合作开发的。在开发ACPI之前，OS主要使用BIOS (Basic Input/Output System)接口进行电源管理、设备发现和配置。这种电源管理方法利用了操作系统的能力来调用系统BIOS进行电源管理。BIOS方案在三个关键方面存在问题。首先，操作系统应用程序的行为可能受到bios配置的电源管理设置的负面影响，导致系统在非预期场景进入休眠。其次，电源管理接口在每个系统上都是专有的，开发人员需要花大量精力了解每个系统的电源管理配置。最后，各种设备的默认设置也可能相互冲突，导致设备崩溃，行为不稳定。
ACPI就是为了解决这些问题和其他问题而开发的。
What is ACPI
ACPI可以被理解为一个与体系结构无关的电源管理和配置框架，作为OS的一个子系统。这个框架建立了一个硬件寄存器集来定义电源状态(睡眠、休眠、唤醒等)。硬件寄存器集可以兼容专用硬件和通用硬件。标准ACPI框架的主要目的是无需直接从OS本地调用固件进行电源管理和系统配置。ACPI作为操作系统和系统固件之间的接口层。
ACPI定义了两种类型的数据结构，它们通过ACPI子系统在系统固件和操作系统之间共享，数据表和定义块(data tables and definition blocks)。这些数据结构是固件和操作系统之间的主要通信机制。数据表存储原始数据，并由设备驱动程序使用。定义块由解释器可执行的字节码组成。
在初始化时，AML解释器从定义块中提取字节码作为可枚举对象。这个可枚举对象集合形成了一个ACPI namespace。OS通过AML解释器与系统硬件进行交互。
定义块字节代码是从ACPI 源语言 (ASL) 代码编译而来的。 ASL语言用来定义ACPI对象并编写控制方法。 ASL编译器将ASL 翻译成 ACPI 机器语言(AML) 字节码。 AML是AML解释器处理的语言，如下图所示。
AML 解释器执行字节码并评估定义块中的对象以允许字节码执行循环构造，条件评估，访问定义的地址空间，并执行应用程序的其他操作要求。 AML 解释器对定义的地址空间具有读/写访问权限，包括系统内存、I/O、PCI配置等等。它通过定义称为对象的入口点来访问这些地址空间。对象可以具有直接定义的值，或者可由 AML 解释器计算。
ACPI namespace是一个操作系统上设备的层次化表示。系统总线是这些 ACPI 设备的枚举根。在其他总线上可枚举的设备，如 PCI 或 USB 设备，通常不在命名空间中枚举。通常具有_HID object (hardware identification object)的设备可以由ACPI进行枚举并加载其驱动程序。具有_ADR object (physical address object)的设备通常不会被 ACPI 枚举，也不会让ACPI 加载其驱动程序。 _ADR 设备通常可以执行所有必要的功能，而无需
涉及 ACPI，但在设备驱动程序无法执行功能或驱动程序需要通信的情况下
对于系统固件，ACPI 可以评估对象以执行所需的功能。
ACPI初始化
系统上电之后，首先由系统固件完成其设置、初始化和自检。然后，在将控制权传递给引导加载程序之前，系统固件使用在固件初始化期间获得的信息来更新 ACPI 表，包括各种平台配置和电源接口数据。扩展根系统描述表 (XSDT) 是 ACPI 子系统使用的第一个表，包含系统上大多数其他 ACPI 表的地址。 XSDT 指向固定的 ACPI 描述表 (FADT)以及操作系统在初始化期间处理的其他主要表。操作系统初始化后，FADT把ACPI 子系统指向区分系统描述表 (DSDT)，它是命名空间的开始，因为它是第一个包含定义块的表。
然后，ACPI 子系统处理 DSDT 并使用 ACPI 定义块构建ACPI namespace。XSDT 还指向辅助系统描述表 (SSDT) 并将它们添加到namespace。 ACPI数据表提供有关系统硬件的操作系统原始数据。操作系统使用 ACPI 表构建namespace后，它开始遍历namespace并加载遇到的所有 _HID 设备的驱动程序。
在 ACPI 初始化图中，在将控制权交给引导加载程序之前，系统固件根据需要更新 ACPI 表。 XSDT是OS ACPI子系统使用的第一个表，并包含系统上大多数其他 ACPI 表的地址。 XSDT指向FADT，SSDT 和其他主要的 ACPI 表。 FADT 将 ACPI 子系统引导到 DSDT，，因为 DSDT 是namespace第一个包含定义块的表。然后 ACPI 子系统使用DSDT 并开始从定义块构建 ACPI namespace。 XSDT 还指向 SSDT并将它们添加到命名空间。
2 Introduction
主要目标
- 权衡成本/功能，使所有计算机系统能够实现主板配置和电源管理功能：
- 计算机系统包括（但不限于）台式机、移动设备、工作站和服务器机器。
- 可以自由选择从非常简单到非常激进的解决方案，同时仍保持完整的操作系统支持。
- 增强电源管理功能和稳健性：
- 过于复杂在平台固件中无法实现的电源管理策略，可以在OS中实现，廉价的电源管理硬件也可以支持非常复杂的电源管理政策。
- 将来自用户、应用程序和硬件的电源管理信息收集到OS中将实现更好的电源管理决策和执行。
- 操作系统中电源管理算法的统一将减少固件和操作系统之间的冲突并将提高可靠性。
- 促进和加速电源管理的全行业实施：
- OSPM 和 ACPI 减少了整个行业对电源管理的冗余投资，
因为这项投资和功能将被收集到操作系统中。这将使行业参与者将他们的努力和投资集中在创新上。 - 操作系统可以独立于硬件发展，允许所有兼容 ACPI 的机器获得操作系统改进和创新的好处。
- 为配置主板设备创建一个强大的接口：
- 不用考虑现有接口，采用新的高级设计
Power management 基本原理
ACPI 是抽象接口，所以OS和硬件可以单独演进。而且ACP在跨操作系统和处理器 更易于进行移植。 老的电源管理方法的存在以下问题：
- 对电源管理的支持越少，越会阻碍应用程序供应商支持或利用它。
- 将电源管理功能移到操作系统中，从而使每台机器上都可用其功能。尽管功能级别因机器而异，但用户和应用程序将在所有 OSPM 机器上看到相同的电源接口和语义。
- 这将使应用程序供应商更加愿意为其产品添加电源管理功能。
- 传统电源管理算法受到平台固件可用信息的限制。这限制了可以实现的功能。
- 集中用户、应用程序和硬件的电源管理信息允许实现更强大的功能。
- 设备功能通常需要全局一致的电源决策。
- 平台固件处理电源管理会非常复杂。因为它局限于硬件的静态配置。
- 平台固件能够保留和管理的状态信息要少得多（因为操作系统在管理它）。
- 电源管理算法在操作系统中统一实现比在OS和硬件中分开实现要好。
– 因为可以加载额外的 ACPI 表（定义块），操作系统可以处理动态机器配置。
– 由于平台固件的功能较少且更简单，因此更容易来实施和支持。
ACPI框架
Target Audience
本规范适用于以下用户：
• OEMs building hardware containing ACPI-compatible interfaces
• Operating system and device driver developers
• All platform system firmware developers
• CPU and chip set vendors
• Peripheral vendors
3 术语
本规范定义了一些术语，主要分为三部分，通用术语、全局系统状态(对用户可见)、设备状态(对用户不可见)。
通用术语General ACPI Terminology
| 术语 | 含义 |
|---|---|
| Advanced Configuration and Power Interface (ACPI) | ACPI规范 |
| ACPI Hardware | 支持OSPM特性的硬件 |
| ACPI Namespace | 包含命名object的分层树桩结构，object可以是数据，控制方法等。namespace由DSDT生成 |
| ACPI Machine Language (AML) | 控制方法和数据的伪代码 |
| Advanced Programmable Interrupt Controller (APIC) | intel的中断控制器，支持多处理器 |
| ACPI Source Language (ASL) | ASL编译结果为AML |
| BIOS | Basic Input/Output System，在这特指传统的x86 BIOS，不是一个通用概念 |
| Boot Firmware | 描述boo阶段的firmware通用术语， |
| Control Method | 用来描述OS如何执行的简单硬件动作 |
| Device | 通用术语，用来指代任何计算、输入输出、存储单元。例如CPU、GPU、BMC、TPM、NIC、HDD |
| Device Context | device存储的可变数据，如果device进出某个power状态，由OSPM负责保存恢复这些信息 |
| Device Firmware | 仅有特定设备使用的firmware，通常由设备厂提供 |
| Differentiated System Description Table (DSDT) | OEM提供DSDT给OS来识别其配置信息 |
| Firmware | any BIOS or firmware on a platform |
| Fixed ACPI Description Table (FADT) | 包含ACPI硬件寄存器块以及DSDT的物理地址 |
| Fixed Features | ACPI规范中定义的特性，限制硬件的行为 |
| Fixed Feature Events | ACPI规范汇总定义的事件 |
| Fixed Feature Registers | 系统I/O空间中的一组硬件寄存器 |
| Global System Status | 对用户可见的全系统状态，在ACPI规范中有G0~G3 |
| Host Processor | 通常指运行用户程序的CPU |
| Host Processor Boot Firmware | host processor运行的firmware |
| Host Processor Runtime Firmware | host processor运行时程序 |
| Intel Architecture-Personal Computer (IA-PC) | intel架构PC机 |
| Legacy | 平台固件决定电源管理策略。区别于OSPM系统的架构 |
| Legacy BIOS | x86 BIOS架构，正在被UEFI替代 |
| Legacy Hardware | 计算机系统不支持ACPI or OSPM |
| Legacy OS | 不能感知电源管理功能的OS |
| Management Firmware | BMC使用的firmware |
| Namespace | 一块连续的地址空间 |
| Non-Host Processor | 在一个平台中指代微控制或者协处理器 |
| Platform | 一个平台由多个设备组成，这些设备组装在一起并协同工作以提供特定的计算功能，平台的示例包括笔记本电脑、台式机、服务器、网络交换机、刀片等，它们独立于操作系统、用户应用程序或用户数据。 |
| Platform Boot Firmware | 平台所有boot firmware的集合。它们做一些平台基本的初始化，然后把控制权交给加载程序或OS。这之后，boot firmware就没有用处了 |
| Platform Runtime Firmware | 平台所有runtime firmware的集合。OS请求特定功能时，通过firmware提供服务。 |
| Root System Description Pointer (RSDP) | 必须向OS提供RSDP，它仅有目的是提供RSDT和XSDT的物理地址 |
| Root System Description Table (RSDT) | RSDT包含了一组其他系统描述表的物理地址 |
| Secondary System Description Table (SSDT) | 后边分析 |
| eXtended Root System Description Table (XSDT) | 后边分析 |
全局系统状态定义Global System State Definitions
全局系统状态（Gx 状态）适用于整个系统并且对用户可见。全局系统状态由六个主要标准定义：
- 应用软件是否运行？
- 从外部事件到应用程序响应的延迟是多少？
- 功耗是多少？
- 是否需要重启操作系统才能恢复工作状态？
- 拆机安全吗？
- 可以电子方式的进入和退出状态吗？
| state | description |
|---|---|
| G0 Working | 计算机处于运行态。 在这种状态下，外围设备的电源状态可以动态变化。 用户可以通过一些 UI 选择系统的各种性能/功率特性，以使软件针对性能或电池寿命进行优化。 系统实时响应外部事件。 在这种状态下拆卸机器是不安全的。 |
| G1 Sleeping | 计算机消耗少量电力的状态，没有运行程序，从最终用户的角度来看，系统似乎处于OFF状态，例如显示处于关闭的。无需重启即可恢复工作操作系统，但是需要一定的延迟，系统大部分的上下文由硬件保存，其余由系统软件保存。 这是在这种状态下拆卸机器是不安全的。 |
| G2/S5 Soft Off | 计算机消耗最少电量的状态。 没有用户模式或系统模式代码运行。 此状态需要较大的延迟才能返回工作状态。 系统的上下文不会被硬件保存。 必须重新启动系统才能返回工作状态。这种状态下拆卸机器是不安全的。 |
| G3 Mechanical Off | 通过机械方式进入和离开的计算机状态。 意味着没有电流通过电路，并且可以在不损坏硬件或危及服务人员的情况下对其进行操作。 必须重新启动操作系统才能返回工作状态。 不保留硬件上下文。 除实时时钟外，功耗为零。 |
| S4 Non-Volatile Sleep | 一种特殊的全局系统状态，允许在主板断电时保存和恢复系统上下文（相对较慢）。如果系统已被命令进入 S4，操作系统会将所有系统上下文写入非易失性存储介质上的文件并留下适当的上下文标记。 |
设备电源状态定义Device Power State Definitions
设备电源状态是指特定设备的状态，通常它们对用户不可见，因为即使即使系统整体处于工作状态，某些设备也可能处于关闭状态。设备状态适用于任何总线上的任何设备。 它们通常根据四个主要标准来定义：
- 设备的功耗。
- 设备保留了多少上下文。 操作系统负责恢复任何丢失的设备上下文（这可以通过复位设备来完成）。
- 设备驱动程序必须执行的操作才能将设备恢复到完全开启状态。
- 将设备恢复到完全开启状态需要多长时间
| state | description |
|---|---|
| D0 (Fully-On) | 该状态有最高级别的功耗。设备完全激活并且反应灵敏，并能持续记住所有相关上下文。 |
| D1 | 该状态由每个设备类定义。许多设备类没有定义D1。通常D1比D2能保留更多的上下文。 |
| D2 | 该状态由每个设备类定义。许多设备类没有定义D2。一般D2的总线功能会关闭。 |
| D3hot | 该状态由每个设备类定义。设备能够保持被OS枚举的能力。 |
| D3off | 设备完全断电。所有的设备信息都丢失了，因此当设备上电时，OS需要重新初始化。恢复时间最长。 |
睡眠和软关机状态定义Sleeping and Soft-off State Definitions
| G state | S state |
|---|---|
| G0 | S0 |
| G1 | S1、S2、S3、S4 |
| G2 | S5 |
| S state | description | |
|---|---|---|
| S0 | 工作状态。cores处于任意C state，系统上下文不丢失；DDR在D0态；device可以处于任意D状态。 | work |
| S1 | 低唤醒延迟状态。相对于S0，系统进入睡眠，所有core都不执行指令，OSPM需要刷出cache；系统状态没有丢失，硬件维持着所有系统上下文，唤醒后继续执行，不用复位；device尽量处于D3 off状态。 | freeze |
| S2 | 低唤醒延迟状态，与S1类似，但是CPU和系统ram的上下文丢失了；唤醒后，CPU从复位向量开始执行；device尽量处于D3 off状态。用的不多 | |
| S3 | 低唤醒延迟状态。通常称为suspend2ram，相对于S2，DDR刷新速度变慢；pmic处于低功耗模式； | suspend to ram |
| S4 | ACPI支持的最低功耗和最长唤醒状态。通常称为suspend2disk，所有设备都关闭，DDR关闭，平台上下文保存到外部硬盘。 | suspend to disk |
| S5off | 平台仅有BMC上电，SoC下电。唤醒需要一个完整的boot流程。 | shutdown |
处理器电源状态定义Processor Power State Definitions
处理器电源状态(Cx)是G0下面的细分状态，考虑功耗与温度状态。
| C state | description |
|---|---|
| C0 | CPU运行态，执行指令。 |
| C1 | 最低的唤醒延迟。执行WFI/WFE指令即可进入此状态。除了不执行指令，OS观察不到其他影响，随时被中断唤醒。 |
| C2 | C2比C1更节省功耗。相对于C1，有芯片级的时钟低功耗方案。OSPM根据延迟大小决定是否用C2替换C1。除了不执行指令，OS观察不到其他影响，随时被中断唤醒。 |
| C3 | C3比C1、C2更节省功耗。OSPM根据延迟大小决定是否用C3替换C2/C1。进入C3需要刷出cache，之后不需要与其他core做cache同步；可以被中断唤醒；OSPM统计总线一致性请求(硬件支持查询)的历史信息来优化是否进入C3还是C1/C2，总线请求总是活跃那么进入C1/C2，反之C3。 |
| Additional | C4…Cn，各厂家自定义 |
设备和处理器性能状态定义Device and Processor Performance State Definitions
设备和CPU的性能状态(Px)，考虑功耗和性能。
| P state | description |
|---|---|
| P0 | 最大功耗，最大性能 |
| P1 | 比P0的性能和功耗小。 |
| Pn | n取决于具体的设计。Pn是最小的性能和功耗。 |
4 ACPI 概念
ACPI 覆盖范围
ACPI规范涵盖的功能领域如下：
| function | description |
|---|---|
| System power management | 系统电源管理。ACPI定了一套计算机作为一个整体进出睡眠状态的机制，以及任何设备唤醒计算机的通用方法。 |
| Device power management | 设备电源管理。ACPI表描述了主板设备、电源状态、电源控制面、控制方法。允许OS跟进应用使用情况将设备配成不同的电源状态。 |
| Processor power management | 处理器电源管理。当OS空闲但是没有睡眠时，执行ACPI描述的命令将CPU进入低功耗状态。 |
| Device and processor performance management | 设备和处理器性能管理。 |
| Configuration / Plug and Play | 配置/即插即用。ACPI指定用于枚举和配置主板设备的信息，这些信息是分层排列。 |
| System Events | 系统事件。ACPI提供了事件机制，例如热事件、电源管理事件、热插拔事件等。 |
| Battery management | 电池管理。OS需要smart battery subsystem interface或者control method battery interface。控制电池的行为比如调整电池不足电池警告的临界点。 |
| Thermal management | 热管理。ACPI提供了一个简单可拓展的模型，允许OEM定义热区、热指示器、冷却热区的方法。 |
| Embedded Controller | 嵌入式控制器。ACPI定义了OS总线和嵌入式控制器之间的标准硬件软件通信接口。这使得OS驱动程序能够与控制器通信进而使用这些资源。 |
| SMBus Controller | SMbus控制器。ACPI定义了OS与SMbus之间的硬件软件接口。 |
OSPM的使命是优化平台并进行系统的电源/性能/热管理。任何符合符合ACPI的平台，其硬件/固件/non-OS软件禁止独立于OSPM进行上述功能的操作。独立于OSPM进行操作这些功能将会破坏OSPM/ACPI的目的并可能导致系统功能的破坏。有两个例外：1、OSPM的延迟不足以补救不利的热条件。在这种情况下，平台可能会执行故障热控制机制降低系统的性能，平台同时会通知OSPM。2、平台包含主动冷却设备，在这种情况下基于硬件的主动冷却设备不会影响OSPM。
电源状态
一般情况，计算机在工作和睡眠状态切换。在工作状态下，用户程序会不断的分发执行，单个设备可以在不同的Dx状态，CPU可以在不同的Cx状态。任何设备可以被系统关闭，因为它们可以快速的唤醒。工作状态的不同子状态在运算速度、功耗、热量、噪音之间取得平衡。
当计算机处于空闲状态或用户按下电源按钮时，操作系统会将计算机置于其中之一睡眠 (Sx) 状态。在睡眠状态下不会发生用户可见的计算行为。睡眠子状态只能关闭一部分系统功耗，但是如果用户按下电源开关，OS就会把系统上下文保存到NVS文件系统。支持legay BIOS的计算机在加载支持ACPI的OS之后会转换为工作工作。
-
电源按钮
在旧系统中，电源按钮通常会强制机器进入软关闭或机械关闭，或者在笔记本电脑上，强制它进入某种睡眠状态。没有考虑到用户策略（例如用户希望机器“在不到 1 秒的时间内打开”，所有上下文都与用户“关闭”机器时一样），或应用程序功能（如保存用户文件）。
在 OSPM 系统中，有两个开关。一个开关是将系统转换到机械关闭状态。出于法律原因（例如，在某些欧洲国家）需要一种机制立即下电计算机。另一个是“主”电源按钮，它所做的只是向系统发送请求。系统对此请求的处理取决于来自用户偏好、用户功能请求和应用程序数据的策略问题。 -
不同平台电源管理特性
- mobile PC
移动PC具有强大的电源管理功能，OSPM允许增强的节能技术以及一些用户自定义策略。 - Desktop PCs
Ordinary “Green PC”：生产电脑，电源管理功能较少，通常不需要睡眠状态。Home PC：家庭娱乐电脑，需要热控制功能。 - Multiprocessor and Server PCs
服务器通常需要最大的节能，日件模式：服务器的保持在工作状态，尽可能地把未使用设备置于低功耗状态。夜间模式：服务器看起来像Home PC，它们睡得尽可能深，并能唤醒在指定的时间响应业务请求。
系统电源管理System Power Management
基于用户偏好设置以及APP使用情况，OS知道系统和设备的情况，OSPM动态的将系统整体和设备是低功耗状态。
设备电源管理Device Power Management
- 设备电源管理模型
-
分布式设备电源状态
对于系统上的每个硬件设备，OS上有一个电源策略所有者(Power Policy Owner)负责不断的决策设备的最佳电源状态。策略通常是为一类设备定义，根据需要结合应用程序活动、用户场景和其他操作状态来决策。 -
分层设备电源状态控制
当设备下电时，设备驱动程序按照设备、总线、平台的层次顺序执行，唤醒时则相反的顺序。 -
OS协调
ACPI定义了信息和行为要求，OSPM能够通知Power Policy Owner有关支持的状态和唤醒能力，并协调各级别的驱动程序来控制功耗。OSPM在这个角色中负责确保设备电源管理与系统电源管理相协调，例如进入睡眠状态、空闲状态。
-
电源管理标准
为每个 I/O 互连定义标准，对于独立硬件供应商 (IHV) 不必花费额外的时间编写软件来管理他们的硬件，对于与操作系统供应商，I/O 互连标准允许将电源管理代码集中在每个 I/O 互连的驱动程序。最后，I/O 互连驱动的电源管理允许操作系统跟踪给定 I/O 互连上所有设备的状态。当所有设备都处于给定状态（例如，D3 - 关闭）时，操作系统可以将整个 I/O 互连置于适合该状态的电源模式（例如，D3 - 关闭）。
I/O 互连级电源管理规范为许多总线编写，包括： PCI、 PCI Express、 CardBus、 USB、 IEEE 1394 -
设备电源状态
为了统一术语并在设备之间提供一致的行为，对设备的电源状态使用了标准定义。通常，这些状态是根据以下标准定义的:
1、功耗-设备使用的功率。
2、设备上下文-设备的上下文有多少被硬件保留。
3、设备驱动程序-设备驱动程序必须做恢复设备完全打开。
4、恢复延迟-恢复设备完全打开所需的时间。
更具体地说，每一类设备(例如，调制解调器、网络适配器、硬盘等)的电源管理规范更精确地定义了该类的电源状态和电源策略。 -
设备电源状态定义
设备电源状态定义是与设备无关的，但是同一个总线上的设备类别必须支持一些一致的电源特性集。这些特定类别的电源特性也必须标准化:
1、设备电源状态特性的标准定义(目标功耗级别、状态变化延迟和上下文丢失)。2、设备最小功率能力。3、设备功能特征。4、设备唤醒策略。设备类电源管理规范为每一类设备定义了这些电源状态特征。
参见附录A:设备类规格。
控制设备电源
详细参考第7章节。
处理器电源管理
在工作状态下，为了进一步节省功耗，操作系统会在空闲时将 CPU 置于低功耗状态（C1、C2 和 C3）。 在这些低功耗状态下，CPU 不运行任何指令，并在中断时唤醒，例如 OS 调度程序的定时器中断。 OS会通过PM QoS来评估CPU在哪个低功耗状态下最合适（功耗和延迟不同）。
详细参考Processor Configuration and Control章节。
设备和处理器性能状态
性能状态允许 OSPM 在性能和节能之间进行权衡。性能状态转换发生在活动/执行的设备状态，必须注意确保性能状态转换不会对系统造成不利影响。调节设备和处理器使其性能与对应的功耗相匹配。
详细参考Processor Configuration and Control章节。
配置/即插即用
除了电源管理之外，ACPI接口还提供控制方法和信息来让OSPM配置主板资源。ACPI 定义块，包括区分系统描述表 (DSDT) 和辅助系统描述表 (SSDT)。
电池管理
管理低电量、电池警告等跳变点、获取电池容量、剩余电量、计算剩余用时、低电量级别(告警、低电量、严重低电量)
热管理
ACPI使用thermal zone来表示一块温度区域。通常整个PC是一个大的thermal zone，但是OEM也可以划分为多个逻辑thermal zone，更精细化的管理。
主动和被动降温模型。Passive cooling，OS通过降低系统性能减少热量的方式降低温度。Active cooling，OS通过散热设备加快散热降低温度。
灵活的平台架构支持
ACPI 提供了另一种平台接口模型，该模型消除了非PC架构的 ACPI 硬件要求。这提供了一定的灵活性，方便在低功耗硬件设计方面进行创新和差异化，同时支持多个OS。
缩写对照表
| 缩写 | 全拼 |
|---|---|
| AML | ACPI machine language |
| ASL | ACPI Source Language |
| XSDT | extended root system description table |
| FADT | fixed ACPI description table |
| DSDT | differentiated system description table |
| OSPM | OS power management |
