How UEFI Manages Power States During ACPI Parsing

This article explains how the Unified Extensible Firmware Interface (UEFI) coordinates hardware power states while creating, configuring, and parsing Advanced Configuration and Power Interface (ACPI) tables. It covers the firmware execution phases, the role of ACPI drivers and protocols, how wake and sleep vectors are evaluated, and the final transition of power management responsibilities to the Operating System Power Manager (OSPM).

Firmware Execution Phases and Static Power States

During the pre-boot environment, UEFI executes across distinct phases: Security (SEC), Pre-EFI Initialization (PEI), Driver Execution Environment (DXE), and Boot Device Selection (BDS). Throughout these stages, the system operates in a static, fully powered working state (ACPI System State S0).

Individual hardware devices reside in their default, fully operational device states (D0) to allow enumeration, configuration, and firmware loading. UEFI does not dynamically alter runtime processor states (C-states) or device power states (D-states) during normal execution; instead, it establishes the baseline hardware registers required for basic input/output, memory training, and peripheral initialization.

ACPI Table Construction and Installation

During the DXE phase, platform-specific DXE drivers assemble and publish ACPI tables using the EFI_ACPI_TABLE_PROTOCOL. These tables include:

  • RSDP (Root System Description Pointer) and XSDT (Extended System Description Table): Map the memory locations of all other ACPI tables.
  • FADT (Fixed ACPI Description Table): Contains fixed hardware registers for power control, such as power management timers, SMI commands, and sleep registers (PM1a_CNT_BLK, PM1b_CNT_BLK, SLP_TYP, SLP_EN).
  • DSDT (Differentiated System Description Table) and SSDTs (Secondary System Description Tables): Contain definition blocks written in ACPI Source Language (ASL) and compiled into ACPI Machine Language (AML), describing device hierarchies and power management methods (_PS0, _PS3, _PR0).
  • FACS (Firmware ACPI Control Structure): Allocates memory for hardware wake flags and the OS waking vector.

While these tables are installed, the UEFI environment validates table checksums and updates base addresses. The firmware parses these tables to ensure pointers match the hardware resources allocated during PCI bus enumeration and MMIO mapping.

Handling Sleep and Wake Transitions (S3 Resume)

The primary scenario where UEFI actively inspects ACPI structures to manage an active power state change is the ACPI S3 (Suspend-to-RAM) resume path:

  1. Detection: During early PEI, the chipset-specific PEIM (PEI Module) checks the power management status registers (such as PM1_STS) to determine if the wake event corresponds to an S3 resume rather than a cold boot.
  2. Table Traversal: The firmware locates the FACS table using the RSDP stored in reserved memory or non-volatile storage.
  3. Restoring Context: UEFI reads the Firmware_Waking_Vector or X_Firmware_Waking_Vector field inside the FACS.
  4. Handoff: Instead of launching a full DXE discovery cycle, UEFI restores minimal chipset context, restores cache control, and jumps directly to the physical memory address specified by the OS waking vector, transitioning the machine back to S0 under OS control.

AML Interpretation Restrictions in UEFI

UEFI does not implement a full, dynamic ACPI Machine Language (AML) virtual machine within the standard DXE phase. Device-level power methods (such as evaluating _ON, _OFF, or _PSx control methods) remain inert while UEFI is running.

Instead, UEFI prepares the ACPI hardware register blocks specified in the FADT. If a device requires an intermediate power toggle during the pre-boot phase (for example, powering up a discrete GPU or spinning up a hard disk), UEFI uses native UEFI device drivers communicating directly with the hardware through PCI configuration space or MMIO, rather than parsing AML bytecode.

Transition of Authority to the OSPM

When UEFI transfers execution to the operating system bootloader via the ExitBootServices() API:

  1. UEFI terminates all boot-service-specific drivers and reclaims the corresponding memory regions.
  2. Runtime ACPI memory regions (EfiACPIReclaimMemory and EfiACPIMemoryNVS) are preserved intact and presented to the operating system.
  3. The Operating System Power Manager (OSPM) assumes ownership of the parsed ACPI tables.
  4. The OS loads its native AML interpreter, binds power management drivers to the device tree described in the DSDT and SSDTs, and takes dynamic control of runtime power transitions across all system, processor, and device states.