ACPI Firmware Tables Explained: DSDT, SSDT, and More

ACPI, the Advanced Configuration and Power Interface, defines structures and mechanisms that let an operating system discover platform configuration and participate in power, thermal, and other platform management. On a modern PC, firmware prepares ACPI data and the operating system consumes it during boot and, for some objects, later at run time.

That makes ACPI a boundary between firmware and the operating system rather than a replacement for UEFI firmware itself. UEFI covers the pre-boot environment, boot services, runtime services, executable formats, and related firmware interfaces. ACPI supplies a standardized description of platform hardware and control methods that the operating system can use after it takes control of the machine.

ACPI does not put the entire platform description into one flat file. The Root System Description Pointer leads the operating system to a root table such as the XSDT on modern systems. The XSDT in turn points to other system description tables. Microsoft documents examples including the FADT, MADT, DSDT, optional SSDTs, boot graphics data, debugging information, and firmware performance data.

Different tables serve different purposes. The FADT carries fixed ACPI configuration information and includes the reference used to reach the DSDT. Other tables can describe interrupt controllers, NUMA relationships, hardware error sources, timers, PCI configuration space, or architecture-specific facilities. Which optional tables exist depends on the platform and the applicable ACPI requirements.

The Differentiated System Description Table, or DSDT, is the primary definition block for the platform. Secondary System Description Tables, or SSDTs, can extend that description. Linux kernel documentation describes the DSDT and SSDT definition blocks as the material that forms the hierarchical ACPI namespace, whose topology reflects the underlying platform hardware.

There is one DSDT, while multiple SSDTs can be present. The ACPI specification defines SSDTs as a continuation of the DSDT: additional definition blocks can add namespace content but do not simply replace existing DSDT definitions. SSDTs are useful for modular platform descriptions and can also support descriptions that are loaded dynamically where the platform and operating system support that model.

ACPI device descriptions are more than passive name-and-value records. ACPI defines Source Language, or ASL, for expressing named objects and control methods. Those definitions are compiled into ACPI Machine Language, or AML, bytecode stored in definition blocks such as the DSDT and SSDTs. The operating system includes an ACPI interpreter that can evaluate those objects and methods.

This is why an ACPI namespace can express platform-specific behavior without requiring the operating system to contain hard-coded knowledge of every motherboard wiring decision. Firmware can describe devices, resources, dependencies, power relationships, and methods behind standardized ACPI object names while the operating system supplies the ACPI execution environment.

An ACPI node can tell the operating system that a device exists, identify compatible hardware, describe resources, expose power capabilities, or provide firmware methods needed to manage the platform. That description can participate in device enumeration and driver matching, but it is not generally the code that implements the full function of a GPU, Wi-Fi adapter, storage controller, or other complex device.

The operating system still uses its driver model and device-specific drivers where required. ACPI and drivers therefore cooperate at different layers: firmware describes platform integration and standardized controls, while drivers implement OS-facing device behavior and communicate with hardware through the interfaces appropriate to that device.

SMBIOS is commonly surfaced by inventory tools because it contains structured records about the computer and its components. That makes it useful for questions such as which system or baseboard firmware reports, how memory devices are described, and other management-oriented inventory data.

ACPI is instead concerned with the operating system’s platform configuration and management interface. Seeing a motherboard name or memory-module record in SMBIOS does not mean that information came from the DSDT, and seeing an ACPI device or power method does not make it an SMBIOS record. Both can originate from firmware while serving different contracts.

Because the operating system uses ACPI data to understand platform topology, resources, device relationships, and power-management behavior, firmware defects can surface as operating-system symptoms. Problems can be platform-specific and may change with a BIOS/UEFI firmware update, an operating-system update, or a kernel workaround.

That does not make manual DSDT editing a normal consumer troubleshooting step. Linux supports table override mechanisms primarily for development and debugging scenarios, and Windows platform documentation treats ACPI tables as firmware-supplied platform data. For an ordinary PC, firmware updates, vendor documentation, driver/OS updates, and reproducible diagnostics are safer first steps than replacing compiled firmware tables by hand.

Tools can expose table signatures such as DSDT, SSDT, FACP/FADT, APIC/MADT, MCFG, SRAT, and many others, but a signature alone does not explain whether a table is required on a particular architecture, whether the operating system uses every field, or whether a reported value is responsible for a problem. ACPI evolves across specification revisions and includes architecture- and platform-specific requirements.

When investigating a table, first identify the platform, ACPI revision, table signature, OEM identifiers and revision, then compare the relevant object or field with the applicable specification and operating-system documentation. Treat decompiled AML as firmware implementation detail that needs evidence and context rather than as a list of safe settings to edit.