ACPI
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 computer hardware components, including power states, thermal zones, and device resources, to optimize system performance, energy efficiency, and interoperability across diverse platforms such as PCs, servers, and embedded systems.[1] It facilitates Operating System-directed Power Management (OSPM), allowing the OS to control power consumption, sleep modes, and hardware events without relying on proprietary BIOS mechanisms, thereby replacing earlier standards like Advanced Power Management (APM).[1] The specification includes mechanisms for device enumeration, resource allocation (e.g., IRQs, memory ranges), and event handling via tables and control methods interpreted in ACPI Machine Language (AML).[1] As of May 2025, the current version is 6.6, maintained by the UEFI Forum.[1] ACPI originated in the mid-1990s as a collaborative effort by Intel, Microsoft, and Toshiba to address limitations in legacy BIOS power management, such as platform-specific implementations and OS-firmware conflicts, with initial contributions from companies like HP and Phoenix Technologies.[1] 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.[1] Subsequent versions evolved to support emerging hardware: version 2.0 (2000) added 64-bit addressing and thermal zones; 3.0 (2004) enhanced multiprocessor and PCI Express support; 4.0 (2009) introduced error handling via ACPI Platform Error Interface (APEI); 5.0 (2011) added Non-Volatile Dual In-line Memory Module (NVDIMM) and ARM architecture compatibility; and 6.0 (2015) incorporated persistent memory and USB Type-C features.[1] Since 2013, the UEFI Forum has overseen development through the ACPI Special Interest Group (SIG), ensuring broad industry adoption and updates for modern technologies like CXL and RISC-V.[2] Key components of ACPI include a hierarchical namespace 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.[1] It supports power management 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).[1] Configuration features enable hot-plug operations, resource descriptors for buses like PCIe and USB4, and hardware interfaces such as Embedded Controllers and Platform Communication Channel (PCC).[1] Version 6.6 introduces enhancements like the CXL Early Discovery Table for Compute Express Link support, Platform Health Assessment Table (PHAT) for reliability monitoring, and improved memory power management via the Memory Power State Table (MPST).[1] ACPI's scope extends to x86, ARM, and RISC-V architectures, powering features in operating systems like Windows and Linux for battery management, sleep/wake transitions, and error reporting.[3] Its benefits include reduced power usage through dynamic state transitions, enhanced hardware portability via standardized abstraction, and improved system reliability with features like Reliability, Availability, and Serviceability (RAS2) extensions.[1] By abstracting hardware details, ACPI minimizes OS development efforts and supports evolving technologies without frequent firmware updates.[4]Overview
Definition and Purpose
The Advanced Configuration and Power Interface (ACPI) is an open industry standard that defines interfaces for device configuration and power management in computer systems.[5] It was originally developed by Intel, Microsoft, and Toshiba, with subsequent contributions from other vendors such as Hewlett-Packard.[6] ACPI enables operating systems to discover and configure hardware components in a vendor-neutral manner, extending beyond traditional BIOS limitations to support modern system capabilities.[5] The primary purpose of ACPI is to facilitate Operating System-directed configuration and Power Management (OSPM), allowing the operating system to exert direct control over power states, hardware resource allocation, and device enumeration without reliance on BIOS-specific code.[7] 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.[5] This approach ensures consistent behavior across diverse hardware platforms while supporting advanced features like interrupt routing and bus enumeration.[8] 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.[9] In mobile systems, it extends battery life by optimizing resource usage and enabling fine-grained control over components like batteries and processors.[5] Additionally, ACPI improves system responsiveness by allowing rapid state transitions and replaces legacy methods such as Advanced Power Management (APM) with a more robust, OS-integrated framework.[5] Its scope encompasses hardware discovery akin to Plug and Play standards, alongside enforcement of power policies for both individual devices and the entire platform.[7]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.[8] These root tables, located via the Root System Description Pointer (RSDP) in low memory, enable the operating system present manager (OSPM) to discover and load subsequent tables that describe the system's hardware features beyond fixed registers.[8] 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.[8] 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.[8] 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.[8] 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.[8] Central to this model is ACPI Machine Language (AML), a compact bytecode 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.[10] AML enables the namespace to support both static data and dynamic operations, ensuring portable hardware abstraction across diverse platforms. Control methods within the namespace provide standardized interfaces for device identification and resource management, implemented as AML code under specific object names. The _HID (Hardware ID) method returns a unique identifier, such as a Plug and Play EISA-compatible ID or ACPI string (e.g., "PNP0C0C" for a power button), allowing OSPM to match devices with appropriate drivers during enumeration.[11] The _CRS (Current Resource Settings) method delivers a package of resource descriptors detailing the device's current allocations, including interrupt, I/O, and memory ranges, which OSPM uses to assess and reconfigure resources without hardware probing.[11] 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.[11] These methods collectively support Plug and Play 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).[12] The control blocks, accessed in system I/O or memory space, feature fields such as SLP_TYPx to specify sleep states (S1-S5) and SLP_EN to trigger transitions, allowing OSPM to initiate low-level power management without relying solely on namespace methods.[12] 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 Intel Corporation, Microsoft Corporation, and Toshiba Corporation to establish a standardized framework for power management and hardware configuration in personal computers.[13] This development was driven by the growing popularity of mobile computing, which demanded more efficient battery life and seamless power control, while addressing the shortcomings of prior standards like Advanced Power Management (APM) and Plug and Play (PnP) BIOS.[14] APM's reliance on BIOS-level, real-mode calls limited operating system (OS) oversight, resulting in inflexible power policies and compatibility issues across hardware vendors, whereas PnP BIOS inadequately handled dynamic device enumeration and power integration.[14] 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.[6] 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.[13][6] 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).[13] 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.[13] 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.[6] Early adoption of ACPI 1.0 faced significant hurdles due to immature hardware and firmware implementations, particularly in BIOS configurations from the late 1990s.[15] 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.[15] 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 BIOS updates became more reliable.[14][15]Specification Versions and Evolution
The ACPI specification has evolved significantly since version 2.0, incorporating enhancements for power management, hardware configuration, and support for emerging architectures. Version 2.0, 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.[16] 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 Itanium.[17] 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, Non-Uniform Memory Access (NUMA) configurations, PCI Express and SATA device descriptions, ambient light sensors for display power management, user presence detection, and an extended thermal model with multiple cooling devices per zone.[17] 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, Intelligent Platform Management Interface (IPMI) integration, USB 3.0 support in device location descriptors, and hardware error reporting structures.[18] 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 Arm 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.[19] In October 2013, ownership of the specification transferred from Intel, Microsoft, and others to the UEFI Forum, broadening contributor involvement and aligning ACPI with UEFI advancements for diverse platforms including Arm.[20] 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.[21] 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.[22] 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).[1] This progression reflects a shift toward modern hardware paradigms, with increased focus on Arm and RISC-V processors for edge and server applications, low-power IoT optimizations like S0ix and LPIT, and security enhancements such as confidential computing and error reporting to meet demands for resilient, efficient systems. The UEFI Forum's stewardship since 2013 has fostered open collaboration, ensuring ACPI remains adaptable to evolving technologies while maintaining backward compatibility.[2]Architecture
Core Architecture
The Advanced Configuration and Power Interface (ACPI) employs a layered architecture that separates hardware, firmware, and software components to enable operating system-directed power management (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 firmware 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.[7] During system boot, the ACPI namespace—a hierarchical tree structure representing the device's logical view—is constructed through table loading and enumeration. The BIOS locates the Root System Description Pointer (RSDP) in low memory or the EFI System 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 memory, followed by Secondary System Description Tables (SSDTs) to extend the namespace without overwriting existing definitions. OSPM then parses this namespace using an AML interpreter to enumerate the device tree, evaluating objects for hardware discovery and configuration capabilities.[8] 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 interrupt, triggered when enabled status bits in power management or GPE registers are set, allowing OSPM to respond without firmware intervention once control is transferred from System Management Mode (SMM). GPE blocks, defined in the FADT as GPE0_BLK and GPE1_BLK, handle device-specific events like thermal changes or docking through status (GPEx_STS) and enable (GPEx_EN) registers, which OSPM polls or services via interrupt handlers. This model ensures efficient, low-latency communication between hardware changes and OSPM actions, such as invoking control methods for event processing.[12][8] Resource allocation in ACPI distinguishes between static and dynamic assignments to support Plug and Play functionality. Static resources are fixed at boot 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 enumeration, coordinates allocations across dependent devices using extended resource descriptors, and applies selections via the _SRS (Set Resource Settings) method to update hardware registers.[11]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.[23] Initially developed by Intel 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.[23] The latest release, version 20250807 from August 2025, ensures ongoing alignment with evolving ACPI standards.[24] Key components of ACPICA include the AML interpreter, which executes bytecode from ACPI tables; the OS services layer, which abstracts platform-specific operations; and tools such as the AML debugger and disassembler for analysis and troubleshooting.[25] Additionally, it supports the compilation of ACPI Source Language (ASL) into AML via the iASL compiler, facilitating the development and validation of ACPI tables by firmware engineers.[26] 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.[23] 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.[27] 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.[26] 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.[25] 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.[28] 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.[29]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.[7] OSPM's primary responsibilities encompass policy-driven decisions for transitioning between power states, negotiating resource allocations for motherboard 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.[7][30] 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 temperature 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.[31][32] 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.[33]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.[34] Sleeping states S1 through S3 provide progressive power reductions while preserving context for quick resumption. In S1, the system enters a low-latency sleep where processor caches are flushed but most context remains intact, with clocks halted except for essential ones like the real-time clock (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 context. 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 context 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 context preserved, necessitating a full boot sequence for reactivation, and power is minimal or zero.[34]| State | Description | Power Consumption | Wake Latency | Context Preservation |
|---|---|---|---|---|
| S0 | Working | Full | None | All |
| S1 | Sleep | Low | Low | Most (except caches) |
| S2 | Sleep | Very low | Low | Memory |
| S3 | Suspend-to-RAM | Minimal | Low | Memory only |
| S4 | Hibernate | Near zero | High | Saved to disk |
| S5 | Soft off | Off | Full boot | None |
| State | Description | Power Consumption | Context Retention | Restore Time |
|---|---|---|---|---|
| D0 | Fully on | Full | All | Immediate |
| D1 | Intermediate | < D0, > D2 | Partial | Short |
| D2 | Intermediate | < D1, > D3 | Minimal | Medium |
| D3hot | Off (hot) | Minimal | Optional | Long |
| D3cold | Off (cold) | Zero | None | Longest |