Loading article…
Advanced Configuration and Power Interface ( ACPI ) は、オペレーティングシステムがコンピュータのハードウェアコンポーネントを検出および構成し、電源管理(未使用のハードウェア コンポーネントをスリープ状態にするなど)、自動構成(プラグ アンド プレイやホット スワップなど)、およびステータス監視を実行するために使用できるオープン スタンダードです。1996 年 12 月に発表され、Windows 98およびWindows 2000で初めて利用可能になったACPI は、Advanced Power Management (APM)、MultiProcessor Specification、およびPlug and Play BIOS (PnP) Specification を置き換えることを目的としています。[ 1 ] ACPI は、電源管理と構成ポリシーを決定するためにプラットフォーム固有のファームウェアに依存していた以前の BIOS 中心のシステムとは対照的に、電源管理をオペレーティングシステムの制御下に置きます。[ 2 ]この仕様は、オペレーティングシステム主導の構成および電源管理( OSPM ) システムの中核を成しています。ACPI は、デバイスのファームウェア ( BIOS、UEFIなど)、コンピュータのハードウェアコンポーネント、およびオペレーティングシステム間のハードウェア抽象化インターフェイスを定義します。[ 3 ] [ 4 ]
ACPIは内部的に、システムファームウェア（UEFIまたはBIOS ）を通じて提供される命令リスト（「メソッド」）を使用して、利用可能なコンポーネントとその機能をオペレーティングシステムカーネルに通知します。カーネルはこの命令リストを解析します。その後、ACPIは組み込みの最小限の仮想マシンを使用して、 ACPIマシン語で記述された目的の操作（ハードウェアコンポーネントの初期化など）を実行します。
Intel、Microsoft、東芝が当初この規格を開発し、その後HP、Huawei、Phoenixも参加しました。2013年10月、ACPI規格のオリジナル開発者であるACPI Special Interest Group（ACPI SIG）は、すべての資産をUEFI Forumに移管することに合意し、今後の開発はすべてUEFI Forumで行われることになりました。[ 5 ]最新バージョン標準規格6.6は2025年5月13日にリリースされた。[ 6 ]
ファームウェアレベルの ACPI は、ACPI テーブル、ACPI BIOS、および ACPI レジスタの 3 つの主要コンポーネントで構成されています。ACPI BIOS は ACPI テーブルを生成し、ACPI テーブルをメインメモリにロードします。ファームウェア ACPI 機能の大部分は、ACPI テーブルに格納されているチューリング完全なドメイン固有の低レベル言語であるACPI マシン言語( AML )のバイトコードで提供されます。[ 7 ] ACPI テーブルを使用するには、オペレーティングシステムに AML バイトコードのインタプリタが必要です。参照 AML インタプリタ実装は、ACPI コンポーネントアーキテクチャ( ACPICA ) によって提供されます。BIOS 開発時には、AML バイトコードはACPI ソース言語( ASL ) コードからコンパイルされます。 [ 8 ] [ 9 ]
ACPI Component Architecture ( ACPICA ) は、主に Intel のエンジニアによって作成され、オペレーティングシステム関連の ACPI コードのオープンソースのプラットフォーム非依存のリファレンス実装を提供します。[ 10 ] ACPICAコードは、Linux、 Haiku、ArcaOS [ 11 ]、FreeBSD [ 8 ]で使用されており、それぞれのオペレーティングシステム固有のコードで補完されています。
ACPI仕様の最初の改訂版は1996年12月にリリースされ、16ビット、24ビット、32ビットのアドレス空間をサポートしていました。ACPIが64ビットアドレス空間のサポートとマルチプロセッサワークステーションおよびサーバーのサポートを受けたのは、2000年8月のバージョン2.0になってからのことです。
1999年、当時のマイクロソフトCEOビル・ゲイツは電子メールで、LinuxはACPIのおかげで何もしなくても恩恵を受けられるだろうと述べ、Windows専用にすることを提案した。[ 12 ] [ 13 ] [ 14 ]
2004年9月、改訂版3.0がリリースされ、ACPI仕様にSATAインターフェース、PCI Expressバス、256個以上のプロセッサに対応するマルチプロセッササポート、環境光センサー、ユーザー存在検知デバイスのサポートが追加され、さらに従来のプロセッサ中心のサポートを超えて熱モデルが拡張されました。
2009年6月にリリースされたACPI仕様の改訂版4.0では、設計に様々な新機能が追加されました。中でも特筆すべきは、USB 3.0のサポート、論理プロセッサのアイドル状態のサポート、およびx2APICのサポートです。
当初、ACPIはx86アーキテクチャ専用でしたが、2011年12月にACPI仕様のリビジョン5.0がリリースされ[ 15 ] 、 ARMアーキテクチャのサポートが追加されました。リビジョン5.1は2014年7月にリリースされました[ 16 ]。 2025年5月にリリースされた最新のリビジョン6.6では、RISC-Vのサポートが追加されました。
Microsoft のWindows 98 はACPI を実装した最初のオペレーティングシステムでしたが、[ 17 ] [ 18 ]その実装は多少バグがあったり不完全だったりしました[ 19 ] [ 20 ]。ただし、それに関連する問題の一部は、第一世代の ACPI ハードウェアが原因でした[ 21 ]。Windowsの後のバージョン、macOS (x86 macOS のみ)、eComStation、ArcaOS [ 22 ]、FreeBSD (FreeBSD 5.0 以降[ 23 ] )、NetBSD (NetBSD 1.6 以降[ 24 ] )、OpenBSD (OpenBSD 3.8 以降[ 25 ] )、HP-UX、OpenVMS、Linux、GNU/Hurd、SolarisのPC版など、他のオペレーティングシステムは、少なくとも ACPI をある程度サポートしています。[ 26 ] Windows Vistaのような新しいオペレーティングシステムでは、コンピュータに ACPI 準拠の BIOS が必要であり、Windows 8以降ではS0ix/モダン スタンバイ状態が実装されています。[ 27 ]
Windowsオペレーティングシステムは、ACPIイベントにアクセスするためにacpi.sys [ 28 ]を使用します。
Linuxカーネルの2.4シリーズではACPIのサポートは最小限でしたが、カーネルバージョン2.6.0以降ではより優れたサポートが実装され（デフォルトで有効になっています）。[ 29 ]古いACPI BIOSの実装はバグが多い傾向があり、その結果、後続のオペレーティングシステムではサポートされていません。たとえば、Windows 2000、Windows XP、およびWindows Server 2003は、BIOSの日付が1999年1月1日以降である場合にのみACPIを使用します。[ 30 ]同様に、Linuxカーネル2.6は、BIOSの日付が2001年1月1日より前である場合、ACPIを使用しない可能性があります。[ 29 ]
Linuxベースのオペレーティングシステムは、acpidを介してACPIイベントの処理を提供できます。[ 31 ]
OSPM互換のオペレーティングシステムがACPIを有効にすると、電源管理とデバイス構成のあらゆる側面を排他的に制御するようになります。OSPMの実装は、デバイスドライバに対してACPI互換の環境を公開する必要があり、これにより特定のシステム、デバイス、およびプロセッサの状態が公開されます。
ACPI仕様では、ACPI準拠のコンピュータシステムに対して、次の4つのグローバル「Gx」状態と6つのスリープ「Sx」状態が定義されています。[ 32 ] [ 33 ]
仕様では、レガシー状態も定義されています。これは、ACPIをサポートしないオペレーティングシステムの状態です。この状態では、ハードウェアと電源はACPIを介して管理されないため、事実上ACPIが無効になります。
デバイスの状態D0～D3はデバイスに依存します。
CPUの電源状態C0～C3は、以下のように定義されます。
追加の状態は、一部のプロセッサについてメーカーによって定義されています。これらは_CSTメソッドを介してシステムに報告されます。[ 40 ]例えば、IntelのHaswellプラットフォームにはC10までの状態があり、コア状態とパッケージ状態を区別しています。違いは、パッケージにはプロセッサ コアだけでなく、L3 キャッシュ、メモリ コントローラ、その他の I/O 機能などのコンポーネントも含まれることです。[ 41 ]同様に、AMD Zen 2 CPU は、コア コンプレックスと Infinity Fabric の C 状態と P 状態を区別しています。[ 42 ]
コンポーネントのグループ（たとえば、複数のコアを含むパッケージ）のアイドル状態を記述するには、_LPI（低電力アイドル）メソッドが使用されます。[ 43 ]これは、パッケージC10のS0ixスリープまたはPCH SLP_S0状態を記述するために使用されるIntelのプライベートLPITテーブルと混同しないでください。[ 44 ]
デバイスまたはプロセッサが動作している間（それぞれ D0 および C0）、いくつかの電力性能状態のいずれかになります。これらの状態は実装に依存します。P0 は常に最高の性能状態であり、P1 から Pn は順に性能が低い状態です。状態の総数はデバイスまたはプロセッサに依存しますが、16 を超えることはありません。[ 45 ]
Pステートは、 IntelプロセッサではSpeedStep 、 AMDプロセッサではPowerNow!またはCool'n'Quiet 、 VIAプロセッサではPowerSaverとして知られるようになった。
ACPI協調プロセッサ性能制御（CPPC）に基づく新しい制御方式の簡単な説明については、 「動的周波数スケーリング」§ 「自律周波数スケーリング」を参照してください。この新しい方式では、数百もの状態が可能となり、プロセッサは指定された状態範囲から自律的に選択できます。
ACPI準拠システムは、「機能固定ハードウェア（FFH）インターフェース」または、機器メーカー（OEM）が提供するプラットフォーム固有のACPIマシン言語（AML）に依存するプラットフォーム非依存のハードウェアプログラミングモデルのいずれかを介してハードウェアとやり取りします。
機能固定ハードウェアインターフェイスは、プラットフォームメーカーがパフォーマンスと障害回復のために提供するプラットフォーム固有の機能です。標準的なIntelベースのPC には、Intel によって定義された固定機能インターフェイスがあり、[ 47 ]コア機能のセットを提供することで、起動時や重大なシステム障害が発生した場合に、ACPI 準拠システムが基本的な機能を提供するために完全なドライバスタックを必要とする必要性を軽減します。
ACPIプラットフォームエラーインターフェース（APEI）は、チップセットやRAMなどのハードウェアエラーをオペレーティングシステムに報告するための仕様です。
ACPI は、ACPI 準拠のオペレーティングシステムとシステムファームウェア ( BIOSまたはUEFI ) 間のインターフェースを提供する多くのテーブルを定義しています。これには、たとえば RSDP、RSDT、XSDT、FADT、FACS、DSDT、SSDT、MADT、MCFG が含まれます。[ 48 ] [ 49 ]
これらのテーブルは、プラットフォームに依存しない方法でシステムハードウェアを記述することを可能にし、固定形式のデータ構造またはAMLとして表現されます。主なAMLテーブルはDSDT（差別化システム記述テーブル）です。AMLは、OS互換性を拡張するためのテーブルのパッチ適用などの目的で、IntelのiASL（オープンソース、ACPICAの一部）などのツールで逆コンパイルできます。[ 50 ] [ 51 ]
ルートシステム記述ポインタ（RSDP）はプラットフォームに依存した場所に配置され、他のテーブルを記述します。
Windows プラットフォーム バイナリ テーブル (WPBT) と呼ばれるカスタム ACPI テーブルは、ベンダーが Windows OS にソフトウェアを自動的に追加できるようにするために Microsoft によって使用されています。Lenovoは、この機能を使用してSuperfishなどの有害なソフトウェアをインストールしていたことが発覚しています。[ 52 ]また、Gigabyte Technology も、この機能を使用して OEM ソフトウェアをインストールしていたことが発覚しています。Samsungは、Windows Update が無効になっている PC を出荷していました。[ 52 ] Windows 7 より前のバージョンの Windows はこの機能をサポートしていませんが、代替の手法を使用できます。この動作はルートキットと比較されています。[ 53 ] [ 54 ]
Ubuntu の創設者であるMark Shuttleworth氏は、ACPI はセキュリティリスクであると述べています。[ 55 ]彼は、「次世代デバイスで ACPI を主張することは、リビングルームやデータセンターに巨大なトロイの木馬をインストールすることを主張することと同じだ」と述べ、「デバイスのファームウェアはNSAの親友だ」とも述べています。さらに、「最大の誤りは、NSA だけがこの信頼の立場を悪用している機関だと考えることだ。実際には、すべてのファームウェアは、製造業者の極めて高い無能さと、非常に幅広い機関の極めて高い能力のおかげで、セキュリティ上の問題を抱えた汚水溜めであると考えるのが妥当だ」と述べています。彼は、オープンソースの宣言型ファームウェア (ACPI または非 ACPI) を解決策として提案しています。[ 56 ]
2003年11月、Linuxカーネルの作者であるリーナス・トーバルズは、ACPIを「あらゆる点で完全な設計上の失敗」と評した。[ 56 ] [ 57 ]