Hubbry Logo
ACPIACPIMain
Open search
ACPI
Community hub
ACPI
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
ACPI
ACPI
ACPI
View on Wikipedia
from Wikipedia

Advanced Configuration and Power Interface
AbbreviationACPI
StatusPublished
First publishedDecember 1996
Latest version6.6
May 2025
Organization
Related standardsUEFI
Predecessor
DomainPower management firmware
Websiteuefi.org/acpi

Advanced Configuration and Power Interface (ACPI) is an open standard that operating systems can use to discover and configure computer hardware components, to perform power management (e.g. putting unused hardware components to sleep), auto configuration (e.g. plug and play and hot swapping), and status monitoring. It was first released in December 1996. ACPI aims to replace Advanced Power Management (APM), the MultiProcessor Specification, and the Plug and Play BIOS (PnP) Specification.[1] ACPI brings power management under the control of the operating system, as opposed to the previous BIOS-centric system that relied on platform-specific firmware to determine power management and configuration policies.[2] The specification is central to the Operating System-directed configuration and Power Management (OSPM) system. ACPI defines hardware abstraction interfaces between the device's firmware (e.g. BIOS, UEFI), the computer hardware components, and the operating systems.[3][4]

Internally, ACPI advertises the available components and their functions to the operating system kernel using instruction lists ("methods") provided through the system firmware (UEFI or BIOS), which the kernel parses. ACPI then executes the desired operations written in ACPI Machine Language (such as the initialization of hardware components) using an embedded minimal virtual machine.

Intel, Microsoft and Toshiba originally developed the standard, while HP, Huawei and Phoenix also participated later. In October 2013, ACPI Special Interest Group (ACPI SIG), the original developers of the ACPI standard, agreed to transfer all assets to the UEFI Forum, in which all future development will take place.[5] The latest version of the standard 6.6 was released in 13 May 2025.[6]

Architecture

[edit]

The firmware-level ACPI has three main components: the ACPI tables, the ACPI BIOS, and the ACPI registers. The ACPI BIOS generates ACPI tables and loads ACPI tables into main memory. Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode. A reference AML interpreter implementation is provided by the ACPI Component Architecture (ACPICA). At the BIOS development time, AML bytecode is compiled from the ASL (ACPI Source Language) code.[8][9]

ACPI Component Architecture (ACPICA)

[edit]

The ACPI Component Architecture (ACPICA), mainly written by Intel's engineers, provides an open-source platform-independent reference implementation of the operating system–related ACPI code.[10] The ACPICA code is used by Linux, Haiku, ArcaOS[11] and FreeBSD,[8] which supplement it with their operating-system specific code.

History

[edit]

The first revision of the ACPI specification was released in December 1996, supporting 16, 24 and 32-bit addressing spaces. It was not until August 2000 that ACPI received 64-bit address support as well as support for multiprocessor workstations and servers with revision 2.0.

In 1999, then Microsoft CEO Bill Gates stated in an e-mail that Linux would benefit from ACPI without them having to do work and suggested to make it Windows-only.[12][13][14]

In September 2004, revision 3.0 was released, bringing to the ACPI specification support for SATA interfaces, PCI Express bus, multiprocessor support for more than 256 processors, ambient light sensors and user-presence devices, as well as extending the thermal model beyond the previous processor-centric support.

Released in June 2009, revision 4.0 of the ACPI specification added various new features to the design; most notable are the USB 3.0 support, logical processor idling support, and x2APIC support.

Initially ACPI was exclusive to x86 architecture; Revision 5.0 of the ACPI specification was released in December 2011,[15] which added the ARM architecture support. The revision 5.1 was released in July 2014.[16] The latest revision 6.6, which was released in May 2025, added the RISC-V support.

Operating systems

[edit]
The "It's now safe to turn off your computer" screen in Windows 9x. Most of the computer peripherals are offline, and the only ways to exit this screen are to power off or reset the computer.
The "It's now safe to turn off your computer" screen in Windows NT 4.0. Unlike Windows 9x and later NT releases, most of the essential computer peripherals are working normally, so the user can opt to restart instead of powering off their computer.
The "It's now safe to power off the system" screen in Windows 10 and 11.

Microsoft's Windows 98 was the first operating system to implement ACPI,[17][18] but its implementation was somewhat buggy or incomplete,[19][20] although some of the problems associated with it were caused by the first-generation ACPI hardware.[21] Other operating systems, including later versions of Windows, macOS (x86 macOS only), eComStation, ArcaOS,[22] FreeBSD (since FreeBSD 5.0[23]), NetBSD (since NetBSD 1.6[24]), OpenBSD (since OpenBSD 3.8[25]), HP-UX, OpenVMS, Linux, GNU/Hurd and PC versions of Solaris, have at least some support for ACPI.[26] Some newer operating systems, like Windows Vista, require the computer to have an ACPI-compliant BIOS, and since Windows 8, the S0ix/Modern Standby state was implemented.[27]

Windows operating systems use acpi.sys[28] to access ACPI events.

The 2.4 series of the Linux kernel had only minimal support for ACPI, with better support implemented (and enabled by default) from kernel version 2.6.0 onwards.[29] Old ACPI BIOS implementations tend to be quite buggy, and consequently are not supported by later operating systems. For example, Windows 2000, Windows XP, and Windows Server 2003 only use ACPI if the BIOS date is after January 1, 1999.[30] Similarly, Linux kernel 2.6 may not use ACPI if the BIOS date is before January 1, 2001.[29]

Linux-based operating systems can provide handling of ACPI events via acpid.[31]

OSPM responsibilities

[edit]

Once an OSPM-compatible operating system activates ACPI, it takes exclusive control of all aspects of power management and device configuration. The OSPM implementation must expose an ACPI-compatible environment to device drivers, which exposes certain system, device and processor states.

Power states

[edit]

Global states

[edit]

The ACPI Specification defines the following four global "Gx" states and six sleep "Sx" states for an ACPI-compliant computer system:[32][33]

Gx Name Sx Description
G0 Working S0 The computer is running and the CPU executes instructions. "Away mode" is a subset of S0, where monitor is off but background tasks are running.
G1 Sleeping S0ix Modern Standby,[34] or "Low Power S0 Idle". Partial processor SoC sleep.[35][36] Sub states include S0i1, S0i2 and S0i3. Known to ARM and x86 devices.
S1 Power on Suspend (POS): Processor is powered off, and the CPU(s) stops executing instructions. The power to the CPU(s) and RAM is maintained. Peripherals such as monitor and hard disk may be turned off.
S2 CPU powered off. CPU cache is flushed to RAM.
S3 Commonly referred to as Standby, Sleep, or Suspend to RAM (STR): RAM remains powered, and RAM enters self refresh mode. Most peripherals are turned off. Fans are usually turned off. Requires GPU drivers on Windows.
S4 Hibernation or Suspend to Disk: All content of the main memory is saved to non-volatile memory such as a hard drive, and the system is powered down.
G2 Soft Off S5 Shutdown: system is powered down.
G3 Mechanical Off The computer's power has been totally removed via a mechanical switch (as on the rear of a PSU). The power cord can be removed and the system is safe for disassembly (typically, only the real-time clock continues to run using its own small battery).

The specification also defines a Legacy state: the state of an operating system which does not support ACPI. In this state, the hardware and power are not managed via ACPI, effectively disabling ACPI.

Device states

[edit]

The device states D0–D3 are device dependent:

  • D0 or Fully On is the operating state.
    • As with S0ix, Intel has D0ix states for intermediate levels on the SoC.[37]
  • D1 and D2 are intermediate power-states whose definition varies by device.
  • D3: The D3 state is further divided into D3 Hot (has auxiliary power), and D3 Cold (no power provided):
    • Hot: A device can assert power management requests to transition to higher power states.
    • Cold or Off has the device powered off and unresponsive to its bus.

Processor states

[edit]

The CPU power states C0–C3 are defined as follows:

  • C0 is the operating state.
  • C1 (often known as Halt) is a state where the processor is not executing instructions, but can return to an executing state essentially instantaneously. All ACPI-conformant processors must support this power state. Some processors, such as the Pentium 4 and AMD Athlon, also support an Enhanced C1 state (C1E or Enhanced Halt State) for lower power consumption, however this proved to be buggy on some systems.[38][39]
  • C2 (often known as Stop-Clock) is a state where the processor maintains all software-visible state, but may take longer to wake up. This processor state is optional.
  • C3 (often known as Sleep) is a state where the processor does not need to keep its cache coherent, but maintains other state. Some processors have variations on the C3 state (Deep Sleep, Deeper Sleep, etc.) that differ in how long it takes to wake the processor. This processor state is optional.

Additional states are defined by manufacturers for some processors. They are reported to the system via the _CST table.[40] For example, Intel's Haswell platform has states up to C10, where it distinguishes core states and package states: the difference being that the package not only includes the processor cores, but also components such as the L3 cache, memory controller, and other IO functions.[41] Similarly, AMD Zen 4 CPUs diffentiate between C-states and P-states for the core and the Data Fabric.[42]

For describing the idle states of groupings of components (e.g. a package containing several cores), the _LPI (low power idle) table is used.[43] This should not be confused with Intel's private LPIT table, used to describe S0ix sleep in package C10 or PCH SLP_S0 state.[44]

Performance state

[edit]

While a device or processor operates (D0 and C0, respectively), it can be in one of several power-performance states. These states are implementation-dependent. P0 is always the highest-performance state, with P1 to Pn being successively lower-performance states. The total number of states is device or processor dependent, but can be no greater than 16.[45]

P-states have become known as SpeedStep in Intel processors, as PowerNow! or Cool'n'Quiet in AMD processors, and as PowerSaver in VIA processors.

  • P0 maximum power and frequency
  • P1 less than P0, voltage and frequency scaled
  • P2 less than P1, voltage and frequency scaled[46]
  • Pn less than P(n–1), voltage and frequency scaled

See Dynamic frequency scaling § Autonomous frequency scaling for a brief description of a newer control method based on the ACPI Collaborative Processor Performance Control (CPPC). This new method allows hundreds of possible states, and for the processor to autonomously to choose from a given range of states.

Interfaces

[edit]

Hardware

[edit]

ACPI-compliant systems interact with hardware through either a "Function Fixed Hardware (FFH) Interface", or a platform-independent hardware programming model which relies on platform-specific ACPI Machine Language (AML) provided by the original equipment manufacturer (OEM).

Function Fixed Hardware interfaces are platform-specific features, provided by platform manufacturers for the purposes of performance and failure recovery. Standard Intel-based PCs have a fixed function interface defined by Intel,[47] which provides a set of core functionality that reduces an ACPI-compliant system's need for full driver stacks for providing basic functionality during boot time or in the case of major system failure.

ACPI Platform Error Interface (APEI) is a specification for reporting of hardware errors, e.g. chipset, RAM to the operating system.

Firmware

[edit]

ACPI defines many tables that provide the interface between an ACPI-compliant operating system and system firmware (BIOS or UEFI). This includes RSDP, RSDT, XSDT, FADT, FACS, DSDT, SSDT, MADT, and MCFG, for example.[48][49]

The tables allow description of system hardware in a platform-independent manner, and are presented as either fixed-formatted data structures or in AML. The main AML table is the DSDT (differentiated system description table). The AML can be decompiled by tools like Intel's iASL (open-source, part of ACPICA) for purposes like patching the tables for expanding OS compatibility.[50][51]

The Root System Description Pointer (RSDP) is located in a platform-dependent manner, and describes the rest of the tables.

A custom ACPI table called the Windows Platform Binary Table (WPBT) is used by Microsoft to allow vendors to add software into the Windows OS automatically. Some vendors, such as Lenovo, have been caught using this feature to install harmful software such as Superfish.[52] Samsung shipped PCs with Windows Update disabled.[52] Windows versions older than Windows 7 do not support this feature, but alternative techniques can be used. This behavior has been compared to rootkits.[53][54]

Criticism

[edit]

In November 2003, Linus Torvalds—author of the Linux kernel—described ACPI as "a complete design disaster in every way".[55][56]

See also

[edit]

Further reading

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

ACPI

View on Grokipedia
from Grokipedia
The Advanced Configuration and Power Interface (ACPI) is an open industry standard that defines a hardware-software interface enabling operating systems to discover, configure, and manage components, including power states, zones, and device resources, to optimize , energy efficiency, and interoperability across diverse platforms such as PCs, servers, and embedded systems. It facilitates Operating System-directed Power Management (OSPM), allowing the OS to control power consumption, sleep modes, and hardware events without relying on proprietary mechanisms, thereby replacing earlier standards like (APM). The specification includes mechanisms for device , (e.g., IRQs, ranges), and event handling via tables and control methods interpreted in ACPI Machine Language (AML). As of May 2025, the current version is 6.6, maintained by the Forum. ACPI originated in the mid-1990s as a collaborative effort by , , and to address limitations in legacy power management, such as platform-specific implementations and OS-firmware conflicts, with initial contributions from companies like HP and . The first specification, version 1.0, was released in 1996, introducing basic power states (S0-S5 for systems, D0-D3 for devices) and plug-and-play configuration. Subsequent versions evolved to support emerging hardware: (2000) added 64-bit addressing and thermal zones; 3.0 (2004) enhanced multiprocessor and support; 4.0 (2009) introduced error handling via ACPI Platform Error Interface (APEI); 5.0 (2011) added Non-Volatile Dual In-line Memory Module () and architecture compatibility; and 6.0 (2015) incorporated persistent memory and USB Type-C features. Since 2013, the Forum has overseen development through the ACPI (SIG), ensuring broad industry adoption and updates for modern technologies like CXL and . Key components of ACPI include a hierarchical for device representation, system description tables (e.g., Differentiated System Description Table (DSDT), Secondary System Description Table (SSDT), Fixed ACPI Description Table (FADT)), and control methods defined in ACPI Source Language (ASL) and compiled to AML for execution by the OS interpreter. It supports through processor states (C-states for idle, P-states for performance), thermal policies with cooling devices and fan controls, and event models using System Control Interrupts (SCI) and General-Purpose Events (GPEs). Configuration features enable hot-plug operations, resource descriptors for buses like PCIe and , and hardware interfaces such as Embedded Controllers and Platform Communication Channel (PCC). Version 6.6 introduces enhancements like the CXL Early Discovery Table for support, Platform Health Assessment Table (PHAT) for reliability monitoring, and improved memory via the Memory Power State Table (MPST). ACPI's scope extends to x86, , and architectures, powering features in operating systems like Windows and for battery management, /wake transitions, and error reporting. Its benefits include reduced power usage through dynamic state transitions, enhanced hardware portability via standardized abstraction, and improved system reliability with features like (RAS2) extensions. By abstracting hardware details, ACPI minimizes OS development efforts and supports evolving technologies without frequent firmware updates.

Overview

Definition and Purpose

The Advanced Configuration and Power Interface (ACPI) is an open industry standard that defines interfaces for device configuration and in computer systems. It was originally developed by , , and , with subsequent contributions from other vendors such as . ACPI enables operating systems to discover and configure hardware components in a vendor-neutral manner, extending beyond traditional limitations to support modern system capabilities. The primary purpose of ACPI is to facilitate Operating System-directed configuration and (OSPM), allowing the operating system to exert direct control over power states, hardware resource allocation, and device enumeration without reliance on BIOS-specific code. Through OSPM, ACPI shifts power management responsibilities from firmware to the OS, enabling dynamic adjustments to system and device behaviors based on usage patterns and policy. This approach ensures consistent behavior across diverse hardware platforms while supporting advanced features like interrupt routing and bus enumeration. ACPI delivers key benefits by enhancing energy efficiency through mechanisms that transition idle devices and subsystems into lower power states, thereby reducing overall power consumption. In mobile systems, it extends battery life by optimizing resource usage and enabling fine-grained control over components like batteries and processors. Additionally, ACPI improves responsiveness by allowing rapid state transitions and replaces legacy methods such as (APM) with a more robust, OS-integrated framework. Its scope encompasses hardware discovery akin to standards, alongside enforcement of power policies for both individual devices and the entire platform.

Key Components

ACPI tables form the foundational data structures that convey hardware configuration and capabilities from the platform firmware to the operating system. The Root System Description Table (RSDT) provides 32-bit pointers to other ACPI tables, ensuring compatibility with earlier specifications, while the Extended System Description Table (XSDT) uses 64-bit pointers for modern systems and supersedes the RSDT when present. These root tables, located via the Root System Description Pointer (RSDP) in low , enable the operating system present manager (OSPM) to discover and load subsequent tables that describe the system's hardware features beyond fixed registers. The Differentiated System Description Table (DSDT) serves as the primary table, containing the core Differentiated Definition Block encoded in ACPI Machine Language (AML) to outline the system's devices, resources, and control logic. Secondary System Description Tables (SSDTs) supplement the DSDT by providing additional definition blocks, which are loaded in the order listed in the RSDT or XSDT, allowing for modular extensions to hardware descriptions without altering the base configuration. The ACPI Namespace establishes a hierarchical, tree-structured object model that represents the system's devices, methods, and resources, constructed by the OSPM through the loading and evaluation of definition blocks from the DSDT and SSDTs. This namespace organizes enumerable objects—such as device nodes and data fields—into a unified view accessible via pathnames, facilitating dynamic queries and modifications during runtime. Central to this model is ACPI Machine Language (AML), a compact format compiled from the ACPI Source Language (ASL), which the OSPM's AML interpreter executes to evaluate namespace objects, perform calculations, access I/O or memory, and implement platform-specific behaviors. AML enables the namespace to support both static data and dynamic operations, ensuring portable across diverse platforms. Control methods within the provide standardized interfaces for device identification and , implemented as AML code under specific object names. The _HID (Hardware ID) method returns a , such as a EISA-compatible ID or ACPI string (e.g., "PNP0C0C" for a power button), allowing OSPM to match devices with appropriate drivers during . The _CRS (Current Resource Settings) method delivers a package of resource descriptors detailing the device's current allocations, including , I/O, and memory ranges, which OSPM uses to assess and reconfigure resources without hardware probing. Complementing this, the _SRS (Set Resource Settings) method accepts a similar resource package from OSPM to program the device's hardware registers, enabling precise configuration for non-PCI bus devices and ensuring resource conflicts are resolved. These methods collectively support functionality by abstracting hardware details into interpretable objects. Fixed ACPI hardware registers offer a direct, platform-independent interface for core system control, mapped via addresses in the Fixed ACPI Description Table (FADT). The PM1a and PM1b control and status register blocks (PM1x_CNT_BLK and PM1x_EVT_BLK) handle global power events, with the event blocks including status and enable registers for detecting and arming interrupts from sources like power buttons (PWRBTN_STS/EN) and wake events (WAK_STS). The control blocks, accessed in system I/O or memory space, feature fields such as SLP_TYPx to specify states (S1-S5) and SLP_EN to trigger transitions, allowing OSPM to initiate low-level without relying solely on methods. OSPM interprets these components to orchestrate hardware behavior across the system.

History

Early Development

The Advanced Configuration and Power Interface (ACPI) originated in 1996 as a collaborative effort by Corporation, Corporation, and Corporation to establish a standardized framework for and hardware configuration in personal computers. This development was driven by the growing popularity of , which demanded more efficient battery life and seamless power control, while addressing the shortcomings of prior standards like (APM) and () . APM's reliance on -level, real-mode calls limited operating system (OS) oversight, resulting in inflexible power policies and compatibility issues across hardware vendors, whereas PnP inadequately handled dynamic device enumeration and power integration. The partnership aimed to shift control to the OS—termed OS-directed power management (OSPM)—enabling hardware vendors to build interoperable systems without proprietary extensions. The first ACPI specification, version 1.0, was released on December 22, 1996, following industry reviews involving over 70 companies such as Compaq, Dell, and Hewlett-Packard. It introduced foundational elements including the Root System Description Table (RSDT), which points to other system tables; the Fixed ACPI Description Table (FADT), detailing hardware registers for power events and timers; and a hierarchical ACPI namespace for abstracting devices and resources via ACPI Machine Language (AML). Basic system power states (S-states) were defined, ranging from S0 (working) to S5 (soft off), allowing OS-managed transitions with varying power savings and wake latencies while preserving context where possible. This version was ratified by the PC industry as part of Microsoft's OnNow initiative, with products anticipated for late 1997 to support instant-on capabilities across desktops, laptops, and servers. Early adoption of ACPI 1.0 faced significant hurdles due to immature hardware and implementations, particularly in configurations from the late . Many pre-2001 systems exhibited bugs such as unreliable PCI interrupt routing via the ACPI namespace's _CRS objects and failures in System Control Interrupt (SCI) setup, often requiring OS workarounds like forcing ACPI enablement or disabling local APIC timers to prevent boot hangs. These issues stemmed from the specification's complexity—spanning over 500 pages—and the challenge of transitioning from APM's simpler, firmware-centric model, leading to widespread blacklisting of early hardware in OS kernels until updates became more reliable.

Specification Versions and Evolution

The ACPI specification has evolved significantly since , incorporating enhancements for , hardware configuration, and support for emerging architectures. , released in August 2000, introduced 64-bit addressing support, processor and device performance states (P-states), multiprocessor enhancements for power and performance dependencies, and improved consistency across the namespace for better OS compatibility. These additions built on earlier foundations by enabling more dynamic control over processor frequencies and voltages, facilitating energy-efficient computing on 64-bit systems like . Subsequent versions from 3.0 to 5.0, spanning 2004 to 2014, expanded ACPI's scope to address server-scale systems, storage interfaces, and mobile platforms. ACPI 3.0, released in September 2004, added support for more than 256 processors, (NUMA) configurations, and device descriptions, ambient light sensors for display power management, user presence detection, and an extended thermal model with multiple cooling devices per zone. ACPI 4.0, released in June 2009, introduced low-power idle states (S0ix) for modern standby modes, clock power management domains, x2APIC interrupt controllers, logical processor idling, power metering and budgeting interfaces, (IPMI) integration, support in device location descriptors, and hardware error reporting structures. ACPI 5.0, released in December 2011, focused on system-on-chip (SoC) optimizations with hardware-reduced ACPI profiles, Generic Timer Description Table (GTDT) for systems, Collaborative Processor Performance Control (CPPC) for heterogeneous cores, Platform Communications Channel (PCC) for low-latency messaging, GPIO and Serial Peripheral Bus (SPB) abstractions, and the Device-Specific Data (_DSD) object for vendor extensions. In October 2013, ownership of the specification transferred from , , and others to the UEFI Forum, broadening contributor involvement and aligning ACPI with advancements for diverse platforms including . From version 6.0 onward, released starting in May 2015, ACPI has emphasized heterogeneous computing, security, and non-x86 architectures to support IoT devices, cloud infrastructure, and mobile systems. ACPI 6.0 introduced support for non-volatile memory interfaces, the Low Power Idle Table (LPIT), Processor Properties Topology Table (PPTT) for cache hierarchies, Heterogeneous Memory Attribute Table (HMAT) for memory performance attributes, and enhancements to CPPC for big.LITTLE processor configurations common in Arm-based heterogeneous systems. ACPI 6.5, released in August 2022, further enhanced Arm64 support through updates to the Generic Interrupt Controller (GIC) structures, improved Platform Timer support, and extensions for Scalable Platform Error Handling (RAS2), enabling better error correction and telemetry on Arm servers. The most recent version, 6.6, released on May 13, 2025, adds features for confidential computing including the Confidential Computing Event Log (CCEL) table, Secure Devices (SDEV) extensions, and cache coherency attributes (_CCA); PCIe power management improvements via enhanced wake status bits and hot-plug settings; updates to the I/O Virtualization Reporting Structure (IVRS) for AMD-based virtualization; and RISC-V architecture support with new interrupt controllers (RINTC, IMSIC, PLIC) and the RISC-V Hart Capabilities Table (RHCT). This progression reflects a shift toward modern hardware paradigms, with increased focus on and processors for edge and server applications, low-power IoT optimizations like S0ix and LPIT, and security enhancements such as and error reporting to meet demands for resilient, efficient systems. The UEFI Forum's stewardship since has fostered open collaboration, ensuring ACPI remains adaptable to evolving technologies while maintaining .

Architecture

Core Architecture

The Advanced Configuration and Power Interface (ACPI) employs a layered that separates hardware, , and software components to enable operating system-directed (OSPM) and device configuration. At the hardware layer, ACPI relies on fixed and generic registers, interrupts, and power planes to support device states and event signaling, such as those defined in the Fixed ACPI Description Table (FADT). The layer consists of ACPI Machine Language (AML) code, interpreted by the OSPM to execute control methods that abstract hardware details, including power resource management objects like _PRx for power resources. The software layer, implemented by OSPM, coordinates these elements to manage system power, device enumeration, and performance based on user policies and quality-of-service requirements. During system , the ACPI —a hierarchical representing the device's logical view—is constructed through table loading and enumeration. The locates the Description Pointer (RSDP) in low or the EFI Table, which points to the Root System Description Table (RSDT) or Extended System Description Table (XSDT); these in turn reference tables like the FADT and Differentiated System Description Table (DSDT). The DSDT, containing the primary AML definition block, is loaded first into , followed by Secondary System Description Tables (SSDTs) to extend the without overwriting existing definitions. OSPM then parses this using an AML interpreter to enumerate the device tree, evaluating objects for hardware discovery and configuration capabilities. ACPI's event model facilitates asynchronous hardware notifications to the operating system via the System Control Interrupt (SCI) and General-Purpose Events (GPEs). The SCI serves as the primary OS-visible , triggered when enabled status bits in or GPE registers are set, allowing OSPM to respond without firmware intervention once control is transferred from (SMM). GPE blocks, defined in the FADT as GPE0_BLK and GPE1_BLK, handle device-specific events like changes or docking through status (GPEx_STS) and enable (GPEx_EN) registers, which OSPM polls or services via handlers. This model ensures efficient, low-latency communication between hardware changes and OSPM actions, such as invoking control methods for event processing. Resource allocation in ACPI distinguishes between static and dynamic assignments to support functionality. Static resources are fixed at and require no runtime reconfiguration, typically for non-configurable devices without a _PRS object. Dynamic resources, however, allow OSPM to reassign settings like IRQs or I/O ranges based on system needs; the _PRS (Possible Resource Settings) method returns a buffer of feasible resource descriptors in the same format as _CRS (Current Resource Settings), enabling OSPM to select conflict-free options. OSPM evaluates _PRS during , coordinates allocations across dependent devices using extended resource descriptors, and applies selections via the _SRS (Set Resource Settings) method to update hardware registers.

ACPI Component Architecture (ACPICA)

The ACPI Component Architecture (ACPICA) serves as the reference open-source implementation of the ACPI specification, providing an operating system-independent framework for interpreting ACPI Machine Language (AML) and managing hardware configuration and power features. Initially developed by in 2001 as an open-source subsystem to simplify ACPI adoption across platforms, ACPICA has evolved into a community-maintained project that isolates operating system dependencies, enabling seamless integration into various kernels. The latest release, version 20250807 from August 2025, ensures ongoing alignment with evolving ACPI standards. Key components of ACPICA include the AML interpreter, which executes from ACPI tables; the OS services layer, which abstracts platform-specific operations; and tools such as the AML debugger and for analysis and troubleshooting. Additionally, it supports the compilation of ACPI Source Language (ASL) into AML via the iASL , facilitating the development and validation of ACPI tables by firmware engineers. These elements form a modular structure that allows developers to build custom ACPI subsystems without modifying core code, emphasizing portability across 32-bit and 64-bit environments. ACPICA is widely integrated into open-source operating systems, notably as the acpi_subsystem in the Linux kernel, where it handles table parsing, event processing, and resource management. FreeBSD also incorporates ACPICA for similar purposes, leveraging its tools for system validation and porting ACPI features to new hardware. Beyond kernel use, ACPICA's utilities, including the iASL compiler, are essential for developing and debugging ACPI tables during BIOS/UEFI firmware creation, ensuring compliance and functionality. In terms of development, ACPICA transitioned from Intel-led maintenance to an independent community-driven project, with source code hosted on GitHub under dual BSD and GPL licenses to encourage broad contributions. This shift has sustained regular updates, with the codebase maintaining full compatibility with the ACPI 6.6 specification released in May 2025, including support for new features like RISC-V architecture integration. The project's rigorous release cycle, typically every 1-3 months, focuses on bug fixes, spec conformance, and enhancements to tools for improved developer productivity.

Power Management

OSPM Responsibilities

The Operating System-directed Power Management (OSPM) is the component of the operating system, typically implemented as a kernel-level driver or subsystem, that directs ACPI operations to enforce policies for power management, device configuration, performance optimization, and thermal control on compliant platforms. During operating system boot, OSPM assumes control from any pre-existing legacy hardware mechanisms, becoming the sole authority for coordinating these functions through the ACPI namespace and control methods. OSPM's primary responsibilities encompass policy-driven decisions for transitioning between power states, negotiating resource allocations for and peripheral devices, and managing dynamic events such as device insertion or removal via system notifications. To align platform capabilities with operating system support, OSPM invokes the _OSC (Operating System Capabilities) control method, which allows it to query and request control over specific features—like power management protocols or hardware interfaces—by passing a UUID-identified capabilities buffer to the firmware and receiving a status response indicating granted permissions. In practice, OSPM implements configurable policies such as user-defined timeouts that trigger entry into low-power sleep modes to conserve energy during periods of inactivity, and adaptive thermal management that responds to firmware-reported thresholds by throttling device or processor activity to prevent overheating. These policies enable OSPM to balance system responsiveness with efficiency based on real-time platform feedback. For error handling and safe hardware operations, OSPM relies on dedicated ACPI control methods, including _EJ0, which it executes to initiate the ejection of hot-pluggable devices by coordinating power shutdown and mechanical removal, followed by status checks to confirm successful detachment.

System and Device States

ACPI defines global system power states, known as S-states, which represent the overall power management levels of the entire platform. These states range from fully operational to powered off, balancing power savings with wake-up latency. The working state, S0, maintains full system functionality with all components active and consuming normal power. Sleeping states S1 through S3 provide progressive power reductions while preserving for quick resumption. In S1, the system enters a low-latency sleep where processor caches are flushed but most remains intact, with clocks halted except for essential ones like the (RTC); power draw is low but higher than deeper states. S2 extends this by powering off the processor and caches, requiring a reset on wake, yet maintaining low latency and memory . S3, or suspend-to-RAM, achieves minimal power usage by self-refreshing DRAM while cutting power to nearly all other components, offering low wake latency through enabled wake events. S4, hibernate or suspend-to-disk, saves the entire system to non-volatile storage for the lowest power consumption among sleeping states, though with the highest latency due to full restoration on resume. Finally, S5 denotes soft off, where the system is logically powered down with no preserved, necessitating a full sequence for reactivation, and power is minimal or zero.
StateDescriptionPower ConsumptionWake LatencyContext Preservation
S0WorkingFullNoneAll
S1SleepLowLowMost (except caches)
S2SleepVery lowLowMemory
S3Suspend-to-RAMMinimalLowMemory only
S4HibernateNear zeroHighSaved to disk
S5Soft offOffFull bootNone
Device power states, or D-states, apply to individual hardware components and allow granular independent of the global system state. Every ACPI-compliant device must support D0, the fully on state where the device operates at maximum functionality with full power and context retention. D1 and D2 are optional intermediate states with reduced power—D1 consumes less than D0 but more than D2, retaining more context and requiring less driver intervention on resume, while D2 further lowers power and may lose additional context. D3 represents the off state with zero power and no context, subdivided into D3hot (software-controlled, device remains enumerable but non-functional) and D3cold (hardware-powered off, often used in PCIe for maximum savings, requiring full reinitialization). For PCIe devices, D3hot maintains configuration space access, whereas D3cold removes all power, including auxiliary, for deeper savings. Transitions to these states are controlled via optional _PSx control methods in the ACPI namespace: _PS0 for D0, _PS1 for D1, _PS2 for D2, and _PS3 for D3, executed by the operating system power manager (OSPM) after managing dependent power resources.
StateDescriptionPower ConsumptionContext RetentionRestore Time
D0Fully onFullAllImmediate
D1Intermediate< D0, > D2PartialShort
D2Intermediate< D1, > D3MinimalMedium
D3hotOff (hot)MinimalOptionalLong
D3coldOff (cold)ZeroNoneLongest
State transitions between S-states and D-states are orchestrated by OSPM, which evaluates platform capabilities to select appropriate levels. For system , the _PTS (Prepare To ) method is invoked with the target S-state value (1-5) to perform pre- housekeeping, such as saving context or notifying devices. The platform then sets sleep type registers (SLP_TYPx) and asserts the sleep enable bit (SLP_EN) to enter the state; for S1-S3, caches are flushed and devices transition to compatible D-states. Wake events, enabled through general-purpose events (GPEs) or device-specific interrupts, trigger resumption: in S1-S3, the system de-asserts stop-clock signals and invalidates caches for quick return to S0, while S4 requires to restore saved context from storage. Platform-specific latencies vary; for example, S3 typically resumes in seconds via memory refresh, but S4 can take tens of seconds depending on disk I/O. Device transitions follow similar flows, with OSPM evaluating _PRW (Power Resources for Wake) to enable wake-capable devices in states compatible with the current S-state (e.g., D-state ≥ _SxD and ≤ _SxW). Post-wake, the _WAK method executes to handle device reconfiguration. Suspend and resume flows ensure orderly progression, preventing deeper states for wake-enabled devices to maintain responsiveness. Hybrid sleep combines the low-latency benefits of S3 with the reliability of S4 by writing system to a hibernation file on disk before entering S3; if power is lost during S3, the system resumes from the file as in S4. This approach enhances data safety in unstable power environments without the full latency of pure .

Performance and Processor Management

Processor Power States

Processor power states, known as C-states in the ACPI framework, define the idle modes of the CPU to enable power conservation while the system remains in the global working state (G0). The C0 state represents the fully active mode where the processor executes instructions and can adjust through mechanisms like throttling. Deeper idle states, from C1 to Cn, progressively reduce power consumption by halting execution, gating clocks, flushing caches, and in some cases scaling voltage, though each introduces increasing latency for resuming activity. C1 is the mandatory shallow idle state, entered via a native halt instruction like HLT, which maintains processor and cache coherency with minimal latency, typically under 10 microseconds. Optional states such as C2 and C3 provide greater savings: C2 stops the core clock while preserving cache coherency via chipset support, and C3 flushes caches or disables to allow deeper sleep, but requires handling interrupts for coherency. Higher Cn states (C4 and beyond) extend this hierarchy with platform-specific implementations, often involving voltage reduction for enhanced efficiency. Platform constraints on C-states are enforced through the Fixed ACPI Description Table (FADT), which includes flags like PROC_C1 to mandate C1 support and declares maximum latencies for C2 and C3 to guide the operating system's power manager (OSPM). The FADT assumes symmetric support across processors in a multiprocessor system, limiting all cores to the shallowest common state if any processor lacks deeper capabilities. For implementation, the _CST control method, introduced in ACPI , dynamically describes available C-states per processor, returning details such as register interfaces, state types (e.g., functional or latency-optimized), transition latencies in microseconds, and power consumption in milliwatts. This method overrides fixed registers like P_LVL2 and P_LVL3 used in earlier ACPI versions for entering C2 and C3, enabling flexible, processor-specific configurations. OSPM coordinates entry and exit from these states by evaluating idle duration against latency tolerances, ensuring safe transitions that account for bus master activity and cache flushing requirements. In multi-core environments, advanced features like package-level C-states extend individual core idling to coordinated package sleep, where the _CSD method specifies dependencies such as software-coordinated (SW_ANY or SW_ALL) or hardware-coordinated entry across cores or threads. Latency tolerances, detailed in _CST packages, allow OSPM to select states based on predicted idle time, balancing responsiveness with savings—for instance, avoiding deep Cn states if latency exceeds 100 microseconds for latency-sensitive workloads. Support for these dynamic and hierarchical C-states was formalized starting with ACPI for Cn extensions, with further enhancements in ACPI 6.0 via the _LPI method for low-power idle hierarchies in processor containers. The primary benefit of C-states lies in their trade-offs for power savings: shallower states like C1 achieve modest reductions with near-instant wake-up, while deeper states like C6 or C7 in modern CPUs enable substantial savings through aggressive clock and voltage scaling, albeit with latencies up to several milliseconds that suit prolonged idles. This enables significant energy efficiency in battery-powered or data-center systems, where OSPM policies optimize based on workload patterns to minimize total power draw without excessive performance penalties. Processor C-states integrate with broader ACPI system states to ensure coherent during global operations like transitions.

Performance States (P-States)

Performance states (P-states) in the Advanced Configuration and Power Interface (ACPI) specification enable processors to operate at discrete performance levels while in the active C0 state, allowing dynamic scaling of computational performance and power consumption based on workload demands. P-states are enumerated starting from P0 as the highest-performance state, decreasing to Pn as lower-performance states, with each state tied to a specific combination of operating and voltage that reduces power usage as performance diminishes. This mechanism, introduced in ACPI Specification , supports fine-grained control over processor efficiency without entering idle modes. The primary control method for advertising supported P-states is the _PSS object, an ACPI package under the processor device that lists available states, including details such as core frequency in MHz, power consumption in mW, transition latency, and references to control registers for each state. The _PCT object defines the hardware registers used for reading the current P-state status and writing to transition to a new state, while the _PPC object specifies the number of P-states currently available to the operating system, enabling dynamic enablement or disablement of states based on platform conditions. Operating system (OSPM) coordinates these methods through CPU governors, which select and request P-states via _PCT writes in response to utilization, policy, or policy-driven heuristics, ensuring seamless integration with broader strategies. ACPI P-states incorporate features to handle advanced processor capabilities, such as turbo boost, where frequencies exceeding the base can be exposed as part of higher P-states (e.g., within P0) when conditions like thermal headroom allow, enabling bursts of elevated performance on demand. For heterogeneous multi-core architectures, such as Arm's big.LITTLE design combining high-performance "big" cores with efficiency-focused "LITTLE" cores, per-processor _PSS objects allow independent P-state definitions tailored to each core type, facilitating workload migration and optimized scaling across diverse core clusters. By enabling processors to transition between P-states, ACPI achieves a balance between power consumption and requirements, particularly in battery-powered devices like laptops where lower states reduce energy draw during light loads to extend runtime without compromising responsiveness under heavy utilization. For instance, scaling to a lower P-state can decrease CPU power by adjusting voltage and proportionally, yielding significant gains in dynamic environments.

Operating System Implementation

Windows Support

Microsoft Windows has provided native support for the Advanced Configuration and Power Interface (ACPI) since , where it was first implemented to enable operating system-directed (OSPM) on compatible hardware. The core component of this support is the Acpi.sys kernel , an inbox system file that serves as the primary OSPM implementation, responsible for parsing ACPI tables such as the Root System Description Pointer (RSDP) and Differentiated System Description Table (DSDT), as well as processing ACPI events like power button presses and thermal notifications. Acpi.sys integrates with the Windows kernel to manage hardware resources transparently, allowing applications and the OS to interact with devices without direct involvement. Windows leverages ACPI for comprehensive features, including native handling of states (S-states) from S0 (working) to S5 (soft off), processor idle states (C-states), and performance states (P-states) that dynamically adjust CPU frequency and voltage for energy efficiency. Users can configure power schemes—predefined profiles balancing performance and battery life—through the Powercfg command-line tool, which queries and sets ACPI-defined policies for timeouts, display dimming, and device power states. In , enhancements include improved support for Modern Standby, an S0 low-power idle mode that maintains partial activity for instant resume and connected scenarios on compatible hardware, aligning OSPM responsibilities with ACPI's device model. For compatibility, Windows uses the ACPI _OSC (Operating System Capabilities) method to negotiate control of hardware features with firmware during boot, ensuring the OS can enable or disable capabilities like PCIe (ASPM) to optimize link power without conflicts. This negotiation is crucial for modern platforms, including System-on-Chip (SoC) and Arm-based devices, where Windows provides built-in drivers for ACPI-defined peripherals such as batteries, thermal zones, and embedded controllers. Diagnostic tools in Windows facilitate ACPI troubleshooting: the Event Viewer displays system logs for ACPI events, such as errors from the (e.g., Event ID 13 for timeouts or ID 15 for unexpected data), allowing administrators to monitor power state transitions and hardware interactions. For deeper analysis, , Microsoft's kernel debugger, includes ACPI-specific extensions like !acpiinf for inspecting fixed-feature registers and !acpicache for viewing cached tables, enabling developers to trace OSPM execution and AML (ACPI Machine Language) bytecode issues.

macOS Support

Apple's macOS (formerly macOS X) has supported ACPI since its early versions on x86 hardware, using it for , device discovery, and . The kernel includes an ACPI subsystem that interprets AML and handles OSPM tasks, such as battery status, thermal control, and sleep/wake cycles. On Intel-based Macs, ACPI enables features like Safe Sleep (hybrid S3/S4) and processor power states. With the transition to () starting in 2020, macOS relies less on ACPI, using custom firmware interfaces, but retains compatibility for x86 emulation and certain peripherals. As of (2023) and later, including Sequoia (2024), ACPI support continues for legacy hardware integration. [Note: Sourced generally; specific Apple docs are limited.]

Linux and Other Open-Source Support

Linux kernel developers integrated the ACPI Component Architecture (ACPICA) starting with version 2.4 in January 2001, enabling core ACPI functionality such as AML interpretation and within the operating system. This integration has evolved to provide robust support for ACPI features, including compliance with recent specification versions. Userspace tools complement kernel capabilities; for instance, cpupower facilitates management of processor performance states (P-states) by querying and setting CPU frequencies, while analyzes and reports power usage to identify inefficiencies. ACPI in enables dynamic thermal management through mechanisms like the thermal zone framework, which monitors temperatures and triggers cooling actions such as fan speed adjustments. Battery handling is supported via the power supply class, allowing accurate reporting of charge levels, remaining time, and status updates from ACPI battery devices. Event handling is managed by acpid, a daemon that processes ACPI events like lid closures or power button presses, dispatching them to user-space applications. For advanced usage, the acpi_call kernel module permits invocation of custom ACPI methods, useful for hardware-specific tweaks not covered by standard drivers. Other open-source operating systems have adopted ACPI with varying degrees of completeness. FreeBSD and NetBSD incorporate ports of ACPICA, providing similar core support for power management and device enumeration on x86 platforms. Haiku offers partial ACPI implementation, including CPU idle states but with limitations in sleep modes and event handling. ReactOS includes basic ACPI compatibility for compatibility with Windows hardware, though full feature parity remains under development. Non-x86 architectures present additional challenges; for example, ARM-based systems running Android encounter compatibility issues with ACPI due to reliance on device trees for enumeration, limiting adoption in mobile environments. The open-source community drives ACPI improvements through the Linux ACPI mailing list ([email protected]), where developers submit bug fixes, propose enhancements, and validate implementations against the ACPI specification using tools from the ACPICA suite. This collaborative effort ensures ongoing compatibility and performance optimizations across diverse hardware.

Interfaces

Hardware Interfaces

ACPI employs a set of fixed hardware registers to facilitate direct interaction between the operating system and platform hardware, enabling mode transitions and event notifications. The SMI_CMD register, an I/O port specified in the Fixed ACPI Description Table (FADT), allows the OS Present Manager (OSPM) to switch between ACPI-enabled and legacy modes by writing specific values such as ACPI_ENABLE (typically 0xF1) or ACPI_DISABLE (typically 0xF0) to initiate System Management Mode (SMM) handling. The System Control Interrupt (SCI), another fixed feature defined in the FADT, serves as the primary OS-visible interrupt for ACPI events; it is a shareable, level-active, low-polarity interrupt that triggers upon status changes in general-purpose event (GPE) registers or power management registers, with the SCI_EN bit in the PM1 control register enabling ACPI mode operation. These registers, including PM1 event blocks for status and enable bits (e.g., PWRBTN_STS for power button events), are accessed via I/O or memory-mapped spaces and are byte-aligned for compatibility across platforms. ACPI integrates with various system buses to manage device configuration and power states at the hardware level. For PCI, the Memory Configuration (MCFG) table provides a memory-mapped mechanism to access , allowing OSPM to enumerate and configure PCI devices without relying on I/O port accesses. In PCIe environments, (ASPM) is supported through dedicated registers such as the PCIEXP_WAKE_STS bit in the PM1 , which signals wake events from low-power link states (L0s, L1) to enable transitions back to full power. USB integration occurs via generic serial bus descriptors in ACPI namespace objects, mapping USB ports to power resources and interrupts through the FADT's generic address structure, while I2C and SMBus support is handled similarly via resource descriptors that describe slave addresses and clock frequencies for low-speed peripherals. Platform-specific hardware interfaces extend ACPI's reach to peripherals like keyboards and lids through dedicated controllers. The Embedded Controller (EC), identified by the _HID PNP0C09 in the ACPI namespace, manages asynchronous events such as lid open/close detection and keyboard input; it uses a 256-byte I/O space with EC_SC (status/command) and EC_DATA registers, where events set the SCI_EVT flag to trigger an SCI, prompting OSPM to query details via commands like QR_EC. Starting with ACPI 4.0, (GPIO) events are supported through interrupt connections mapped in the GPE block or via the _AEI object, allowing hardware signals from GPIO pins (e.g., for buttons or sensors) to generate SCIs without requiring an EC. ACPI extensions accommodate non-x86 architectures through defined hardware interfaces for controllers and platform events. For Arm-based systems, support was introduced in ACPI 5.0, with the Generic Interrupt Controller (GIC) integrated via the Multiple APIC Description Table (MADT) and Generic Interrupt Distribution Table (GTDT), where GIC interrupts are described as SPI (Shared Peripheral Interrupts) to route ACPI events like GPEs to the OS. support, introduced in ACPI 6.6, leverages the Platform Interrupt Controller (PLIC) and core-local interrupts through similar MADT extensions, enabling SCI delivery and device wake events on servers while maintaining compatibility with the fixed hardware model.

Firmware and Software Interfaces

The firmware in ACPI-compatible systems, implemented via UEFI or legacy BIOS, generates essential ACPI tables during boot to describe hardware configuration, power states, and device capabilities for the operating system-directed power management (OSPM) subsystem. These tables, including the Root System Description Pointer (RSDP), Extended System Description Table (XSDT), Fixed ACPI Description Table (FADT), and Differentiated System Description Table (DSDT), are constructed by the firmware based on platform hardware and loaded into system memory for OSPM access. Additionally, firmware employs ACPI Source Language (ASL) scripting to define control methods that handle platform-specific quirks, such as custom device initialization or power sequencing, which are compiled into ACPI Machine Language (AML) bytecode for execution by the OSPM interpreter. The _OSI (Operating System Interface) method further enables firmware to detect the host operating system's version and supported features, allowing conditional logic in ASL code to adapt behavior for compatibility across different OSPM implementations. At the software layer, ACPI provides interfaces for user-space applications to query and interact with system resources without direct kernel involvement. Libraries such as libacpi offer a programmatic for accessing ACPI data, including battery status, zones, fan speeds, and presence, by interfacing with kernel-exposed ACPI objects via system calls or device files. Event notifications between and software are facilitated through the Notify() in AML, which or hardware events invoke to signal changes—such as device insertions, power source switches, or thresholds—to OSPM, prompting evaluation of associated control methods. Device status and error handling in ACPI rely on standardized control methods like _STA (Status), which returns a bitmask indicating a device's presence, functional state, and power management support, enabling OSPM to dynamically enumerate or disable hardware as needed. For resource-constrained or embedded systems, hardware-reduced ACPI mode minimizes reliance on dedicated ACPI hardware registers, instead using general-purpose inputs/outputs (GPIOs) or interrupt-signaled events for power and configuration signaling, as defined in the specification to support low-cost designs. Recent extensions to ACPI have expanded its interfaces for emerging use cases. In version 6.6, interfaces for confidential computing were introduced, including new ACPI tables and methods to manage secure enclaves and attestation logs, enabling OSPM to interact with trusted execution environments while preserving isolation from the firmware layer.

Criticism and Limitations

Technical Criticisms

One prominent technical criticism of ACPI centers on its inherent complexity, particularly stemming from the verbose nature of ACPI Machine Language (AML), which results in large ACPI tables and significant debugging challenges. The AML, an interpreted bytecode derived from ACPI Source Language (ASL), requires an OS-level interpreter that adds substantial overhead, as it is not optimized for performance-critical operations like frequent power state changes. This verbosity arises from AML's extensibility, allowing detailed hardware descriptions but leading to bloated tables that complicate parsing and maintenance. Debugging is further hampered by the opaque interaction between BIOS-provided AML and the OS interpreter, often requiring specialized tools like acpidump and iasl to disassemble and override tables, with issues frequently tracing to BIOS bugs or compiler incompatibilities. Backward compatibility requirements impose additional burdens on ACPI implementations, as the specification mandates support for legacy hardware alongside modern features, resulting in fragmented versions across hardware platforms and increased code complexity in the ACPI core. This legacy support enables coexistence of pre-ACPI mechanisms like Advanced Power Management (APM) in mixed environments, but it forces the subsystem to handle outdated hardware abstractions, complicating development and potentially leading to suboptimal performance on newer systems. For instance, firmware must remain compatible with the earliest kernel versions supporting a given ACPI baseline, exacerbating version fragmentation and hindering clean evolution of the standard. ACPI also faces criticism for overhead, especially in older implementations that rely on event polling rather than interrupt-driven mechanisms, introducing unnecessary CPU cycles and in power state transitions. Polling-based governors, such as early Ondemand variants, periodically sample load to trigger frequency changes, which can misjudge short bursts of activity and inflate use—for example, reducing polling intervals from 200 ms to 10 ms during kernel compilation lowers consumption from 475 Wh to 368 Wh but still incurs overhead from repeated checks. State transitions, like those between P-states or C-states, suffer from latency due to AML interpretation and hardware handoffs, with ACPI tables providing latency estimates that OS power managers must navigate, often leading to conservative policies that prioritize stability over . Vendor non-compliance exacerbates these issues, as inconsistent implementations of ACPI elements like Hardware ID (_HID) strings or resource allocation methods frequently cause driver loading failures and enumeration problems. For example, invalid ASL code in BIOS tables can result in mismatches for HID-over-I2C devices, where incorrect _CID values (e.g., not PNP0C50) or misconfigured GPIO interrupts prevent the HIDI2C driver from initializing, leading to devices failing to appear in the OS device manager with errors like Code 10. Such deviations from the specification, often due to OEM-specific optimizations or errors in resource methods, undermine ACPI's goal of standardized hardware abstraction and require extensive workarounds in drivers.

Security and Compatibility Issues

ACPI's ACPI Machine Language (AML) enables the execution of firmware-provided code within the operating system's ACPI interpreter, introducing risks such as due to insufficient isolation and permission checks. For instance, vulnerabilities like CVE-2010-4347 in the kernel's ACPI subsystem allowed unprivileged processes to override control methods, potentially executing arbitrary kernel code. Buffer overflows in AML interpreters exacerbate these issues, as seen in stack-based overflows from poor bounds checking during processing, which can lead to memory corruption and . ACPI interactions with System Management Mode (SMM) further heighten security concerns, as ACPI events can trigger System Management Interrupts (SMIs) that invoke highly privileged SMM handlers with full hardware access. Attacks exploiting this include cache poisoning, where adversaries modify cached SMRAM contents to execute altered SMI code, bypassing chipset locks like D_LCK; such exploits have been demonstrated on multiple x86 platforms including laptops and servers. To mitigate these, ACPI Specification version 6.4 introduces tables like the Windows SMM Security Mitigations Table (WSMT), which enables firmware to report SMM protections to the OS, and the table for secure boot integration. Additional features, such as the Secure Devices (SDEV) table, support trusted execution environments by describing devices protected during boot handoff. Compatibility issues in ACPI often stem from implementation errors, particularly in power state transitions like S3 suspend-to-RAM, where wake events fail to restore display output, resulting in black screens and requiring hard resets. These bugs arise from incomplete ACPI table descriptions or mismatched hardware signaling during resume, affecting diverse systems from laptops to desktops. Support for modern low-power states like S0ix (modern standby) varies on older hardware, as legacy implementations lack the required ACPI extensions, leading to fallback to higher-power modes like S3 or complete incompatibility with connected standby features. On non-PC platforms such as servers, ACPI faces challenges due to its x86-centric design, including limited vendor experience in firmware development and testing, which results in incomplete table implementations and regressions in or device enumeration. Efforts to address legacy compatibility include deprecating outdated tables like the Root System Description Table (RSDT) on 64, as it only supports 32-bit addresses and is ignored in favor of the 64-bit XSDT. The ACPI specification also mandates hardware-reduced models on , excluding legacy fixed-feature hardware interfaces to streamline non-x86 deployments. Recent enhancements in ACPI Specification 6.6 improve security for virtualized environments by introducing the Confidential Computing Event Log (CCEL) table, which logs measurements for confidential VMs (e.g., AMD SEV or Intel TDX) to enable attestation of runtime integrity. It also adds the Storage Volume Key Location (SKVL) table for managing keys in confidential contexts and strengthens TPM integration via the existing TPM2 table, facilitating secure boot and measured launches in virtual machines.

References

  1. https://uefi.org/sites/default/files/resources/ACPI_Spec_6.6.pdf
  2. https://uefi.org/specifications
  3. https://developer.arm.com/dev2/Architectures/ACPI
  4. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/acpi-bios
  5. https://uefi.org/specs/ACPI/6.6/01_Introduction.html
  6. https://news.microsoft.com/source/1997/01/06/intel-microsoft-and-toshiba-publish-specification-for-easy-flexible-power-management-on-desktops-laptops-and-servers/
  7. https://uefi.org/specs/ACPI/6.6/03_ACPI_Concepts.html
  8. https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html
  9. https://uefi.org/specs/ACPI/6.6/07_Power_and_Performance_Mgmt.html
  10. https://uefi.org/specs/ACPI/6.6/20_ACPI_Machine_Language_Specification.html
  11. https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html
  12. https://uefi.org/specs/ACPI/6.6/04_ACPI_Hardware_Specification.html
  13. https://uefi.org/sites/default/files/resources/ACPI_1.pdf
  14. https://queue.acm.org/detail.cfm?id=957774
  15. https://www.kernel.org/doc/ols/2004/ols2004v1-pages-121-132.pdf
  16. https://uefi.org/sites/default/files/resources/ACPI_2.pdf
  17. https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/Frontmatter/Revision_History.html
  18. https://uefi.org/sites/default/files/resources/ACPI_4.pdf
  19. https://uefi.org/sites/default/files/resources/ACPI_5.pdf
  20. https://uefi.org/acpi/specs
  21. https://uefi.org/sites/default/files/resources/ACPI_6.0.pdf
  22. https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5_Aug29.pdf
  23. https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/overview.html
  24. https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/download.html
  25. https://github.com/acpica/acpica
  26. https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/documentation.html
  27. https://www.kernel.org/doc/html/v5.3/driver-api/acpi/linuxized-acpica.html
  28. https://uefi.org/specs/ACPI/6.6/
  29. https://www.intel.com/content/www/us/en/developer/articles/news/acpica-news.html
  30. https://uefi.org/specs/ACPI/6.6/06_Device_Configuration/Device_Configuration.html#_osc-operating-system-capabilities
  31. https://uefi.org/specs/ACPI/6.6/03_ACPI_Concepts.html#system-power-management
  32. https://uefi.org/specs/ACPI/6.6/03_ACPI_Concepts.html#thermal-management-concepts
  33. https://uefi.org/specs/ACPI/6.6/06_Device_Configuration/Device_Configuration.html#_ej0-eject-method
  34. https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping/sleeping-states.html
  35. https://uefi.org/specs/ACPI/6.6/02_Definition_of_Terms/Definition_of_Terms.html
  36. https://uefi.org/specs/ACPI/6.6/07_Power_and_Performance_Mgmt/device-power-management-objects.html
  37. https://learn.microsoft.com/en-us/windows/win32/power/system-power-states
  38. https://uefi.org/specs/ACPI/6.6/08_Processor_Configuration_and_Control.html
  39. https://uefi.org/specs/ACPI/6.6/08_Processor_Configuration_and_Control.html#pss-performance-supported-states
  40. https://uefi.org/specs/ACPI/6.6/08_Processor_Configuration_and_Control.html#pct-performance-control
  41. https://uefi.org/specs/ACPI/6.6/08_Processor_Configuration_and_Control.html#ppc-performance-present-capabilities
  42. https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processors-datasheet-volume-1-of-2/005/intel-turbo-boost-technology-2-0-frequency/
  43. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/xperf/p-states-and-c-states
  44. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/acpi-driver
  45. https://learn.microsoft.com/en-us/windows-hardware/drivers/acpi/supporting-acpi-devices
  46. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/powercfg-command-line-options
  47. https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/enabling-pci-express-native-control
  48. https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-defined-devices
  49. https://learn.microsoft.com/en-us/answers/questions/3966966/event-id-56-acpi-1-in-event-viewer-after-restartin
  50. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/acpi-debugging
  51. https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-acpiinf
  52. https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/NVRAM/Articles/ACPI.html
  53. https://www.kernel.org/doc/html/latest/admin-guide/acpi/index.html
  54. https://wiki.freebsd.org/ACPI
  55. https://man.netbsd.org/acpi.4
  56. https://reactos.org/wiki/Supported_Hardware
  57. https://lwn.net/Articles/950026/
  58. https://uefi.org/specs/ACPI/6.5/04_ACPI_Hardware_Specification.html#fixed-hardware-programming-model
  59. https://uefi.org/specs/ACPI/6.5/04_ACPI_Hardware_Specification.html#the-acpi-hardware-model
  60. https://uefi.org/specs/ACPI/6.5/04_ACPI_Hardware_Specification.html#pm-event-and-control-register-blocks
  61. https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#pci-configuration
  62. https://uefi.org/specs/ACPI/6.5/04_ACPI_Hardware_Specification.html#pci-express-wake-status
  63. https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#usb
  64. https://uefi.org/specs/ACPI/6.5/12_Embedded_Controller_Interface_Specification.html#embedded-controller-interface-description
  65. https://uefi.org/specs/ACPI/6.5/04_ACPI_Hardware_Specification.html#general-purpose-event-register-blocks
  66. https://uefi.org/specs/ACPI/6.6/Frontmatter/Overview.html
  67. https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html
  68. https://manpages.ubuntu.com/manpages/xenial/man3/libacpi.3.html
  69. https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference.html
  70. https://www.kernel.org/doc/ols/2007/ols2007v1-pages-65-74.pdf
  71. https://lwn.net/Articles/237085/
  72. https://uefi.org/sites/default/files/resources/Platform%2520Runtime%2520Mechanism%2520-%2520with%2520legal%2520notice.pdf
  73. https://docs.kernel.org/arch/arm64/arm-acpi.html
  74. https://uefi.org/specs/ACPI/6.5/01_Introduction.html
  75. https://www.researchgate.net/publication/221561417_Event-driven_processor_power_management
  76. https://lenovopress.lenovo.com/lp1836.pdf
  77. https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/troubleshooting-common-errors
  78. https://pdos.csail.mit.edu/papers/vm:apsys13.pdf
  79. https://cyber.gouv.fr/sites/default/files/IMG/pdf/IT_Defense_2010_final.pdf
  80. https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf
  81. https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html
  82. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby
  83. https://events.static.linuxfound.org/sites/events/files/slides/acpi_on_arm64_0.pdf
  84. https://www.kernel.org/doc/html/v6.1/arm64/acpi_object_usage.html
  85. https://documentation-service.arm.com/static/661e74f45d66282bc2cf9cbc
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.