ACPI Tables Explained: DSDT, SSDT, FADT, MADT, and XSDT

Advanced Configuration and Power Interface, or ACPI, defines a firmware-to-operating-system interface for describing platform hardware, configuration, power-management capabilities, interrupts, topology, and other system information. Much of that information is passed in named system-description tables rather than discovered by probing every platform detail directly.

The tables are not interchangeable. Some are roots or directories that lead the operating system to other tables, some contain fixed platform information, and others contain AML definition blocks that build the ACPI namespace. A firmware dump can therefore contain many four-character signatures without each table representing a separate physical device.

The Root System Description Pointer is the entry point into the ACPI system-description-table hierarchy. On UEFI systems, firmware exposes the RSDP through the EFI system table. The RSDP in turn identifies the Root System Description Table or the Extended System Description Table.

The XSDT is the modern form and contains 64-bit physical addresses of other ACPI tables. The older RSDT uses 32-bit addresses. Microsoft documents that Windows prefers the XSDT when both are provided. Think of the XSDT or RSDT as an index of table locations rather than as the place where all ACPI device descriptions live.

The Fixed ACPI Description Table, commonly called FADT or FACP by its signature, carries platform-level information about the fixed ACPI hardware interface and capabilities. The ACPI specification also uses it to provide addresses for structures such as the DSDT and Firmware ACPI Control Structure where applicable.

Because the FADT contains flags and addresses used very early by ACPI-aware operating-system code, a malformed firmware implementation can cause behavior that appears far removed from a visible BIOS setting. That does not mean users should patch FADT fields casually: operating systems and firmware expect the table set to be internally consistent.

The Differentiated System Description Table contains a Definition Block encoded in ACPI Machine Language. When interpreted by the operating system's ACPI subsystem, those definitions create objects in the ACPI namespace representing devices, methods, resources, power relationships, and other platform-specific behavior.

This is why DSDT discussions often include names such as _HID, _CID, _CRS, _STA, or _DSM. Those are namespace objects and control methods defined by ACPI conventions; they are not separate firmware tables. The DSDT is the base definition block from which the namespace is constructed.

Secondary System Description Tables use the same Definition Block format to add more namespace definitions. ACPI 6.6 specifies that multiple SSDTs may be present and that they are loaded after the DSDT in the order presented by the root table.

The specification also states that additional definition tables can add data but cannot overwrite data from previously loaded tables. This lets firmware split optional or dynamically constructed platform descriptions into smaller tables while retaining one base DSDT. The practical result is that a modern PC can legitimately expose many SSDTs.

The Multiple APIC Description Table carries information used to describe the platform's interrupt-controller topology. On x86 systems that includes APIC-related structures; ACPI also defines structures for other architectures such as Arm GIC and RISC-V interrupt controllers.

MADT is therefore different from DSDT and SSDT. It is a structured data table interpreted according to a defined binary layout rather than an AML definition block that adds namespace objects. Seeing the APIC signature in an ACPI table list does not mean it is a driver for the processor's local APIC.

ACPI defines many additional tables because one monolithic firmware structure would be difficult to extend cleanly. Examples include SRAT and SLIT for system-resource affinity and locality information, FPDT for firmware performance data, BGRT for boot graphics information, and error-reporting tables used by platform RAS mechanisms.

Some table signatures are defined by specifications outside the core ACPI document while still participating in the ACPI table-passing mechanism. Platform and architecture requirements also differ, so a table that is expected on one class of machine may be irrelevant or unsupported on another. Absence from one PC is not automatically evidence of broken firmware.

UEFI is the firmware environment and boot interface through which an operating system can locate ACPI data, while ACPI is a separate specification for configuration and power-management interfaces. A firmware setup option may change what ACPI tables contain, but the setup screen itself is not an ACPI table.

Likewise, Windows can expose ACPI-enumerated devices and policy through its own driver and registry layers without making the registry the source of the firmware tables. Keep firmware data, the operating system's interpreted namespace, device drivers, and user-facing settings as separate layers when troubleshooting.

Operating systems and diagnostic tools can expose ACPI tables for inspection, which is useful when debugging firmware, kernel, device-enumeration, or power-management problems. A table dump can establish what firmware actually supplied instead of relying on a BIOS label or a hardware-monitoring guess.

Editing AML or replacing firmware tables is a different risk category. A syntactically valid modification can still change resource declarations, device status, power sequencing, interrupt routing, or vendor-specific methods. For ordinary PC troubleshooting, update firmware and drivers first and use table inspection to narrow a reproducible problem; treat custom ACPI overrides as expert platform-development work, not a generic performance tweak.

Start at the RSDP, follow it to the XSDT or RSDT, then treat the listed tables according to their individual formats. The FADT supplies fixed platform information and important pointers; DSDT and SSDTs contribute AML definitions to the ACPI namespace; MADT describes interrupt topology; other tables carry specialized data.

That model explains why an ACPI dump contains both tables full of binary fields and tables containing AML, why there can be many SSDTs but one DSDT, and why changing one firmware setting can alter the table set the next time the machine boots. ACPI is a contract between platform firmware and the operating system, not one hidden BIOS file that controls every device.