Advanced Configuration and Power Interface
# Advanced Configuration and Power Interface

Das Advanced Configuration and Power Interface (ACPI) ist ein offener Industriestandard für Energieverwaltung in Desktop-Computern, Notebooks und Servern. Er wird von Unternehmen wie ARM, Hewlett-Packard, Intel, Microsoft, Phoenix Technologies und Toshiba entwickelt und stellt Schnittstellen zur Hardware-Erkennung, Gerätekonfiguration und zur Energieverwaltung zur Verfügung.

Insbesondere bekannt ist er durch die verschiedenen Energiesparmodi ACPI-S1 bis S5, die das Advanced Power Management (APM) abgelöst haben.

## Grundlagen

Die Kontrolle über die Energieverwaltung liegt, anders als beim älteren APM-Standard, komplett beim Betriebssystem, das einen besseren Überblick über den momentanen Leistungsbedarf und die Sparmöglichkeiten in einem Rechner hat als das hardwareorientierte BIOS. Mit ACPI ist das BIOS des Rechners nur noch für die Details der Kommunikation mit der Hardware verantwortlich, die Kontrolle liegt aber beim Betriebssystem. Gegenüber APM werden weitergehende Möglichkeiten zum Energiesparen angeboten.

ACPI 1.0, spezifiziert von Intel, Microsoft und Toshiba, wurde im Dezember 1996 veröffentlicht. Mit der Version 2.0 wurde im Juli 2000 Unterstützung für 64-Bit-Architekturen hinzugefügt. Die Version 3.0 vom 2. September 2004 wurde um die Unterstützung für PCI Express und Serial ATA sowie erweiterte SMP-Fähigkeiten ergänzt und auf Grund von Erfahrungen aus der Praxis mit den Implementierungen an einigen Stellen klarer gefasst. Version 4.0 wurde am 16. Juni 2009 veröffentlicht. Zu den Neuerungen gehörte unter anderem die Unterstützung von USB 3.0.

Im Oktober 2013 kam die Weiterentwicklung in die Zuständigkeit vom UEFI Forum. Version 5.1 vom August 2014 brachte Unterstützung für die Armv8-A-Architektur.

Von Intel existiert eine ACPI-Referenzimplementierung mit Namen ACPICA (ACPI Component Architecture), die in leicht angepasster Form unter anderem im Linux-Kernel und den BSD-Derivaten verwendet wird. Die ACPICA implementiert betriebssystemunabhängige Teile der ACPI-Software, hier vor allem den AML-Interpreter, der die von der Hardware bereitgestellten ACPI-Tabellen parst.

ACPI funktioniert nicht auf älterer Hardware. Für volle ACPI-Unterstützung müssen sowohl die Hauptplatine mit ihrem Chipsatz, Timer und BIOS als auch das Betriebssystem und teilweise auch die CPU ACPI-fähig sein. Des Weiteren wird ein Netzteil nach ATX 2.01 oder neuer benötigt.

Die Hardware kann über den System Control Interrupt (SCI) bestimmte Ereignisse an das Betriebssystem signalisieren. Dazu können beispielsweise das Umschalten von Batterie- auf Netzstromversorgung oder das Aufwachen aus dem Energiesparmodus gehören.

## Energieverwaltung – Energiesparmodi nach ACPI-Standard

Die Möglichkeiten, unter Verwendung von ACPI Energie zu sparen, sind vielfältig.

Der gesamte Rechner kann sich in einem von vier Zuständen befinden, die in der ACPI-Spezifikation „G0“ bis „G3“ genannt werden. „G0“ – „Working“ entspricht dabei dem „aktiven“ Zustand, in dem mit dem Computer gearbeitet werden kann, und „G3“ – „Mechanical off“, also „mechanisch abgeschaltet“, ist ein Rechner mit gezogenem Stecker. Dazwischen liegt der Schlafzustand „G1“, in dem große Teile des Rechners abgeschaltet sind, aber aus dem dennoch in kurzer Zeit in den aktiven Zustand zurückgekehrt werden kann, und der „Soft-Off“-Zustand „G2“, der einem Computer auf ATX-Standby-Spannung entspricht.

Innerhalb von G1 kann das System unterschiedlich „tief“ schlafen (S1 bis S4). In den niedrigen Schlafzuständen wird mehr Systemkontext in den schnellen flüchtigen Speichern behalten, so dass das System schneller wieder benutzbar ist. Vor Eintritt in den S4-Zustand wird der Systemkontext auf eine Festplatte geschrieben und beim Aufwachen von dort wiederhergestellt.

### Wichtige Modi im ACPI-Standard

**Prozessorzustände (CPU-States)**

| C-State | Name | Latenz zu C0 | Leistungsaufnahme |
| - | - | - | - |
| C0 | Arbeitszustand (Operating Mode) | | 100 % |
| C1 | Angehalten (Halt) | ≈ 0–01 µs | 040 % |
| C1E | Erweiterter Halt (Enhanced Halt) | ≈ 01–2 µs | 035 % |
| C2 | Gestoppter Takt (Stop Clock) | ≈ 0–59 µs | 030 % |
| C2E | Erweiterter Stop (Extended Stop) | ≈ 0–70 µs | 028 % |
| C3 | Tiefer Schlaf (Deep Sleep) | ≈ 0–85 µs | 026 % |
| C4 | Tieferer Schlaf (Deeper Sleep) | ≈ –150 µs | 024 % |
| C4E/C5 | Erweiterter tiefer Schlaf (Enhanced Deeper Sleep) | ≈ –250 µs | 022 % |
| C6 | Tiefes Abschalten (Deep Power Down) | ≈ –300 µs | 019 % |
| C7 | Tieferes Abschalten (Deeper Power Down) | ≈ –400 µs | 015 % |

Die Leistungsaufnahme weicht zwischen verschiedenen Systemen ab und dient hier lediglich der besseren Vorstellung der unterschiedlichen C-States.

**Gerätezustände (Device-States)**

| D-State | Beschreibung |
| - | - |
| D0 | Gerät ist eingeschaltet und voll funktionsfähig |
| D1 | Zwischenzustand, der je nach Gerät abweichen kann |
| D2 | Zwischenzustand, der je nach Gerät abweichen kann |
| D3 Hot | Gerät ist an einer Stromquelle angeschlossen und kann in einen höheren Zustand wechseln |
| D3 Cold | Gerät hat keine Stromzufuhr und kann keine Kommandos ausführen |

**Ruhezustände (Sleep-States)**

| S-State | Beschreibung |
| - | - |
| S0 | System voll funktionsfähig. Alle Systeme sofort einsatzbereit. |
| S1 | einfachster Schlafmodus; wenige Funktionen sind abgeschaltet, die CPU ist angehalten (Throttle) |
| S2 | erweiterter Schlafmodus. Weitere Komponenten sind abgeschaltet, insbesondere der Cache der CPU |
| S3 | Standby-Modus (Suspend to RAM, STR, Suspend to memory, STM) – die meiste Hardware der Hauptplatine ist abgeschaltet, der Betriebszustand auf einem flüchtigen Speicher gesichert |
| S4 | Ruhezustand (englisch „hibernation“, „suspend to disk“, „STD“) – der Betriebszustand ist auf einem nicht-flüchtigen Speicher gesichert |
| S5 | Soft-Off-Modus, System ist quasi ausgeschaltet, aber das Netzteil liefert Spannung und das System kann mit einem mechanischen Taster („Einschaltknopf“), der an der Hauptplatine angeschlossen ist, oder – je nach Modell und BIOS-Einstellung – auch über die Netzwerkschnittstelle (Wake On LAN) wieder aktiviert werden |

Einzelne Geräte im System können sich in den Zuständen D0 (an) bis D3 (aus) befinden. Wie viel Energie in den beiden dazwischen liegenden Zuständen gespart wird und ob diese überhaupt für ein Gerät zur Verfügung stehen, liegt im Ermessen des Hardware-Herstellers.

Prozessoren können sich innerhalb des G0-Zustands in verschiedenen Unterzuständen befinden. C0 ist dabei der „Arbeitszustand“. Jeder ACPI-fähige Prozessor beherrscht darüber hinaus den C1-Zustand, der aktiviert wird, wenn der Prozessor leerläuft. Dabei wird dem Prozessor die hlt-Instruktion gesendet. Sobald ein Interrupt anliegt, wacht er wieder auf. Besonders Mobilprozessoren kennen darüber hinaus noch die stärkeren Sparzustände C2, C3 oder noch höher, bei denen das Aufwachen zunehmend länger dauert (bei C3 meist bereits so viel, dass es sich nicht lohnt, diesen Zustand einzusteuern, da der Weg zurück nach C0 zu viel Zeit benötigt). In den C-Zuständen geht es zunächst nur um leerlaufende Prozessoren. Darüber hinaus können viele moderne CPUs bei wenig Arbeitsaufkommen in C0 Takt und Kernspannung mehrstufig drosseln. Von diesen „Performance States“ (P-States) kann es beliebig viele geben. Das Betriebssystem muss entscheiden, wie stark es den Prozessor bei niedrigem Arbeitsaufkommen drosselt, ohne dass eine Rückkehr zur höchsten Taktstufe „P0“ unangemessen lange dauert.

## Systembeschreibungs-Tabellen, AML, ASL

BIOS und Chipsatz stellen eine Reihe von Tabellen zur Verfügung, die das System und seine Komponenten beschreiben oder Routinen anbieten, die das Betriebssystem aufrufen kann. Sie sind teilweise in Form eines speziellen Bytecodes, der ACPI Machine Language (AML), hinterlegt. Sie können mit einem Compiler und einem Disassembler zwischen dieser maschinenlesbaren Form und der menschenlesbaren ACPI Source Language (ASL) übersetzt werden. Die benötigten Software-Werkzeuge werden von Intel oder Microsoft zum kostenlosen Herunterladen angeboten, so dass es für Menschen mit ASL-Kenntnissen möglich ist, fehlerhafte Tabellen, hier vor allem die DSDT (Differentiated System Description Table) selbst zu reparieren.

Fehlerhafte Tabellen führen besonders unter alternativen Betriebssystem wie Linux oder xBSD zu Problemen, da einige Hauptplatinenhersteller ihre Tabellen nur unter Microsoft Windows testen. Die Microsoft-ACPI-Implementierung ist dafür bekannt, an einigen Stellen nicht zeichengetreu den Standard zu befolgen, so dass eventuelle Probleme den Herstellern nicht auffallen. Die zwei häufigsten Fehler sind, dass die Tabellen davon ausgehen, dass die Hauptplatine in jedem Fall nur unter Microsoft Windows laufen wird oder sie in bestimmten Funktionen keinen Wert zurückgeben (impliziter Return). Die ACPI-Implementierungen der freien Betriebssysteme müssen um diese Fehler herumarbeiten.

Folgende Tabellen existieren unter anderem:

* RSDP (Root System Description Pointer)
* RSDT (Root System Description Table)
* DSDT (Differentiated System Description Table)
* XSDT (Extended System Description Table)
* FADT (Fixed ACPI Description Table)
* FACS (Firmware ACPI Control Structure)
* SBST (Smart Battery Table)
* ECDT (Embedded Controller Boot Resources Table)
* SRAT (System Resource Affinity Table)
* SLIT (System Locality Distance Information Table)

## Tabellenbeschreibungen

Die Systembeschreibungstabellen sind eine hierarchisch aufgebaute Struktur, die aus mehreren Untertabellen besteht.

### RSDP (Root System Description Pointer)

    Diese Tabelle enthält einen Zeiger auf die weiteren Tabellen und wird von der Hauptplatine entweder in der EBDA (Extended BIOS Data Area) oder im Speicherbereich von E0000h bis FFFFFh abgelegt. Der ACPI-Treiber des Betriebssystems sucht den Speicher nach der „magischen“ Zeichenkette RSD PTR ab und erhält so die Adressen des RSDP und der weiteren Tabellen. Bei Rechnern mit EFI steht der RSDP im EFI und das Durchsuchen des Arbeitsspeichers ist nicht nötig.

### RSDT (Root System Description Table)

    Die RSDT enthält einen oder mehrere Verweise auf andere Tabellen, die Informationen über die Verfahrensweisen – nach bestimmten Standards – die im System eine Rolle spielen, enthalten. So ist im ACPI-System zum Beispiel immer der Verweis auf die Fixed ACPI Description Table (FADT) vorhanden.

### DSDT (Differentiated System Description Table)

    DSDT beschreibt implementierte Systemfunktionen wie Energieverwaltung, Plug and Play und Kühlung in sogenannten Definition Blocks. Definition Blocks enthalten neben Informationen zur Ansteuerung auch in AML (ACPI Machine Language) kodierte Steuerfunktionen. Die für ACPI-Funktionen in der DSDT eingetragenen Definition Blocks bilden die Grundlage für das Funktionieren der ACPI-Funktionen im System. Der DSDT Differentiated Definition Block wird beim Systemboot geladen und verbleibt im Speicher.

### XSDT (Extended System Description Table)

    Diese Tabelle enthält Verweise auf zusätzliche Beschreibungen der Konfiguration und der Systemimplementierung.

### FADT (Fixed ACPI Description Table)

    Diese Tabelle enthält statische, systembedingte Informationen zur Energieverwaltung, sowie Zeiger auf die Firmware ACPI Control Structure (FACS) und die Differentiated System Description Table (DSDT).

### FACS (Firmware ACPI Control Structure)

    Die FACS speichert die vom BIOS eingetragenen systemspezifischen Daten zum ACPI. Diese Daten sind die Grundlage für die Kommunikation von Betriebssystem und Firmware.

### SBST (Smart Battery Table)

    Eine ACPI-Tabelle, die von Plattformen mit Smart Battery Subsystemen benutzt wird. Die Tabelle definiert Energieversorgungsgrenzwerte, die das System veranlassen, in bestimmte Schlafzustände zu wechseln und den Benutzer darauf aufmerksam zu machen.

### SRAT (System Resource Affinity Table)

    Diese Tabelle wird von NUMA-fähigen Betriebssystemen ausgelesen, um lokalen Threads (Aktivitätsträger) auch lokalen Speicher zuweisen zu können. Die Speicherzugriffszeit wird somit minimiert, die Systemleistung steigt. Eine eventuelle „Node-Interleaving“-Funktion, welche in einigen AMD-Opteron-BIOS-Einstellungen zu finden sind, gehört bei NUMA-fähigen Betriebssystemen und geeigneten NUMA-fähigen Anwendungen abgeschaltet, SRAT selbstverständlich an.

### SLIT (System Locality Distance Information Table)

    Diese Tabelle gibt den Abstand der Knoten untereinander an. Das wird benötigt, um angeforderten Speicher auf dem nächsten (d. h. schnellsten) Knoten zu allozieren, falls der lokale Speicher zu klein ist.

## Kritik

ACPI wird dafür kritisiert, besonders kompliziert zu sein. Für andere Betriebssysteme als Windows sei es schwer, in ordentlicher Weise zu implementieren. Intel arbeitet deshalb für den Einsatz in Mobilgeräten an einer Alternative namens Simple Firmware Interface (SFI), empfiehlt jedoch, wenn eine Hardware beides zur Verfügung stellt, stets ACPI zu verwenden.

Wegen Fehlern in der ACPI-Implementierung vieler Hardwarekomponenten muss das Betriebssystem dieses undokumentierte Verhalten mit verschiedenen Methoden korrigieren. Das Betriebssystem Linux gibt sich dem BIOS gegenüber als Windows aus, um den besser getesteten Windows-Modus zu erhalten.

Es gibt einen „ACPI-Machine-Language“-Compiler von Intel und einen von Microsoft. Die Hersteller bevorzugen die Microsoft-Implementierung, weil sie besser mit Windows zusammenarbeitet. Hardware-Defekte durch falsche Stromsparmaßnahmen wollen die Hersteller unbedingt vermeiden.

Bill Gates überlegte 1999, ob er ACPI so gestalten sollte, dass andere Betriebssysteme Probleme mit dessen Implementierung haben:

   “One thing I find myself wondering about is whether we shouldn’t try and make the “ACPI” extensions somehow Windows specific. It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. Maybe there is no way to avoid this problem but it does bother me. Maybe we could define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something related to this.”
   „Ich frage mich, ob wir nicht versuchen sollten, die ACPI-Erweiterungen irgendwie Windows-spezifisch zu machen. Es ist nicht sehr günstig, wenn wir und unsere Partner die Arbeit machen und Linux wunderbar damit funktioniert, ohne etwas beigetragen zu haben. Möglicherweise kann man das nicht vermeiden, dennoch stört es mich. Vielleicht könnten wir die APIs so definieren, dass sie gut mit NT, aber nicht den anderen zusammenarbeiten, obwohl sie offen sind. Oder wir könnten vielleicht etwas in diesem Zusammenhang patentieren.“
