熟悉 x86 電腦的朋友估計對 ACPI 這個名詞不會陌生，在如今的計算機市場上，ACPI廣泛應用于筆記本電腦、臺式機、工作站以及服務器等產品上。新興的 RISC-V 架構要進入桌面/服務器領域，不可避免地會與 ACPI 打上交道。

什么是 ACPI？

ACPI 全稱是 Advanced Configuration and Power Interface（高級配置與電源接口），它是一套開放標準，可供操作系統用于發現和配置硬件、自動配置即插即用和熱插拔設備、進行電源管理以及狀態監控等[1]。

ACPI 的初版規范由英特爾（Intel）、微軟（Microsoft）和東芝（Toshiba）共同制定，在 1996 年 12 月發布。隨后越來越多的公司加入到 ACPI 規范的改進中。2013 年 10 月，ACPI 規范轉交由 UEFI 論壇維護，一直至今。最新的 ACPI 規范已經演變到了 6.6 版本，在 2025 年 5 月發布。

在 ACPI 之前，計算機的電源管理幾乎完全交由底層的 BIOS 固件來控制，這大大限制了操作系統在能耗控制上的功能。ACPI 的出現，取代了 APM（Advanced Power Management）、MPS（MultiProcessor Specification）、Legacy PnP（Plug and Play BIOS）等規范，讓操作系統在電源管理和硬件配置上獲得了更多的自主權，從而實現了OSPM（Operating System-directed configuration and Power Management，操作系統導向的配置和電源管理）系統。

ACPI 框架

一個使用 ACPI 的系統的完整框圖如下：

取自 ACPI specification v6.6[2]

▲

橙色部分是 ACPI 規范所覆蓋的內容，因此 ACPI 定義的是一種軟件和硬件組件的接口規范：

硬件上：

ACPI Register Set：在硬件上實現的 ACPI 寄存器組，為 x86 架構特有。ARM 和 RISC-V 通常用的是 hardware-reduced ACPI，可無需在硬件上實現這些寄存器。

軟件上，定義了多個 ACPI 表（Table），這些表整體可分為兩種類型：

Static Tables：又稱為Data Tables，由裸數據組成，ACPI Driver 可直接讀取表中的內容。

Definition Block Tables：由AML（ACPI Machine Language）字節碼（byte code）組成，它的內容要經AML Interpreter（解釋器）解釋后才能被 ACPI Driver 讀取到。

▲

綠色部分是操作系統中的相關組件，其中：

ACPI Driver：操作系統用于對接 ACPI 的驅動，AML Interpreter 也是屬于其中的一部分。其中有一個比較出名的開源工程ACPICA（ACPI Component Architecture）[3]，它提供了與操作系統無關的一些 ACPI 相關代碼實現，也包括一個 AML Interpreter 的實現。目前 ACPICA 的代碼被用于 Linux、FreeBSD 等系統中，作為 ACPI Driver 的一部分。

OSPM（Operating System-directed configuration and Power Management）：以 ACPI 為核心、由操作系統主導的電源管理子系統的統稱。

▲

藍色部分是硬件或平臺相關的組件，其中：

Platform Firmware是負責啟動機器、實現休眠/喚醒/重啟等接口的固件，通常指 BIOS/UEFI。它也負責生成各個 ACPI 表并提供給操作系統。

ACPI Namespace

前面提到 ACPI 的 Definition Block Tables 由 AML 字節碼組成，而 AML 字節碼的生成流程通常如下圖：工程師使用ASL（ACPI Source Language）語言對硬件信息進行描述，隨后通過 ASL 編譯器（例如 iASL）將其編譯為 AML 字節碼，生成 Definition Block Tables，并打包進固件：

取自 Basic ACPI Source Language (ASL) Constructs Tutorial[4]

從固件中獲取到 ACPI 表后，操作系統中的 AML Interpreter 會解析 AML 字節碼，構造出硬件設備的樹狀層次結構，這種結構稱為 ACPI namespace。操作系統從ACPI namespace中即可獲取到硬件的各種信息：

取自 Basic ACPI Source Language (ASL) Constructs Tutorial[4]

ACPI 與 UEFI 的關系

在 ACPI 出現的場合，通常也能見到 UEFI 的身影。UEFI 全稱是 Unified Extensible Firmware Interface（統一可擴展固件接口），它是計算機固件的一種規范，旨在替代 BIOS。

它的前身是英特爾于 1998 年提出的 Intel Boot Initiative，后改名為 EFI（Extensible Firmware Interface，可擴展固件接口），再于 2005 年改名為 UEFI 并轉交由 UEFI 論壇維護發展至今[5]。UEFI 規范的一個比較出名的實現是由 TianoCore 社區開源的 EDK II 工程[6]。

雖然都是規范，但 ACPI 與 UEFI 關注的點不同：ACPI 是從硬件抽象的角度定義了操作系統發現、配置、管理硬件的規范接口，而 UEFI 定義的是固件與操作系統間軟件層面的規范接口。從兩者最初制定的目的也能看出差異：ACPI 是為了將 BIOS 固件的電源管理等功能以規范的接口交由操作系統來主導，而 UEFI 則是為了替代 BIOS 固件本身。

ACPI 與 UEFI 初版規范的提出都有英特爾的參與，并后面都交由 UEFI 論壇[7]維護，兩者間存在著諸多聯系，但并非強綁定，其他 bootloader（如 U-Boot）也可以支持 ACPI，UEFI 也支持安裝其他的配置表（如 Device Tree）供操作系統使用。不過在個人電腦/服務器領域，UEFI + ACPI 還是目前最常見、最成熟的使用組合。

為什么 RISC-V 需要支持 ACPI？

在討論 RISC-V 為什么需要支持 ACPI 之前，我們可以看一下發展路線十分相似的 ARM：同樣都是起家于嵌入式領域，隨后向個人電腦/服務器領域發起進攻。ARM 所經歷過的挑戰，在 RISC-V 上也同樣存在。

嵌入式與個人電腦/服務器的產品生態差異

嵌入式領域與個人電腦/服務器領域，兩者的產品生態形式有較大的不同：

▲

嵌入式領域的產品，通常會存在一個品牌廠商，整合上游廠商提供的軟、硬件，做成一個高度定制化的最終產品，并對其負責。例如手機，普通用戶通常接觸到的只有蘋果/華為/小米等最終的手機品牌廠商，無法輕易更換手機主板上的硬件，不同手機的固件/操作系統通常也互不通用。

▲

個人電腦/服務器領域的產品，普通用戶能直接接觸到的廠商會多很多，CPU、主板、電源、硬盤、顯卡等均可能來自不同的廠商，用戶可選擇合適的零部件產品，自行搭建出滿足自身需求的機器。各零部件廠商也只對自身的零部件產品負責。軟件操作系統的通用性也更強，一臺機器可以運行 Windows、Ubuntu 等不同的操作系統，同一個操作系統通常也只需一個鏡像就可適配不同的硬件機器。

（當然，目前市面上不乏很多集成化、定制化程度很高的個人電腦產品，例如蘋果公司的 Mac 電腦，或其他一些筆記本電腦，它們的產品形態更接近于手機這樣的嵌入式產品，普通用戶無法輕易自行更換其軟、硬件。不過從整體生態而言，這樣的產品還是相對少數。）

個人電腦/服務器生態中如此多廠商的軟、硬件能相互通用，不可或缺地會存在 “標準”。

個人電腦/服務器生態標準的形成

在 20 世紀 70~80 年代，個人電腦（PC，Personal Computer）剛面向市場時，并不存在統一的標準，不同廠商間的個人電腦互不兼容。1981 年 8 月，IBM 推出了 IBM PC，并隨后公布了上面除 BIOS 外的全部技術資料，并允許第三方公司生產與其兼容的硬件，即采用所謂的開放架構（open architecture）。

此舉大大促進了整個個人電腦產業的發展，IBM PC 逐漸成為事實上的個人電腦 “開放標準”，與該標準兼容的機器都統稱為“IBM PC 兼容機”（IBM PC Compatible）[8]。

隨著計算機技術的發展，到了 1990 年代，IBM 對個人電腦架構的影響力逐漸下降，取而代之的業界標準變成了“Wintel” [9]：Windows + Intel，代指基于英特爾（Intel）的 x86 處理器、運行微軟（Microsoft）的 Windows 操作系統的個人電腦。由英特爾和微軟主導的行業聯盟發布了諸多的軟、硬件規范：UEFI、ACPI、PCI/PCIe 等，“IBM PC 兼容機” 的說法也逐漸被“標準 PC”（standard PC）以及后續的 “ACPI PC” 所取代[8]。

Wintel 架構在 x86 計算機中極具統治力，一直至今。除了臺式機外，筆記本電腦或服務器產品也深受其影響，并且即使機器是基于其他廠商（如 AMD）的 x86 處理器，或運行其他的操作系統（如 Linux），也在很大程度上兼容該架構。

2000 年代的個人電腦主板結構框圖[10]

Device Tree vs ACPI

前面提到說 ACPI 的 ASL 語言可以通過 ACPI namespace 這樣的硬件抽象結構來描述硬件信息，供操作系統使用，而嵌入式領域常用的另外一套技術方案 —— Device Tree，也能對硬件進行抽象。單論硬件抽象功能，兩者并無孰優孰劣之分，那隨著 ARM/RISC-V 進入個人電腦/服務器領域，Device Tree 是否有可能伴隨 ARM/RISC-V 的使用慣性而帶入進來，并成為與 ACPI 抗衡甚至取代 ACPI 的新行業標準？

目前來看暫無這樣的趨勢。因為在個人電腦/服務器領域，Device Tree 相比 ACPI 還是有以下兩點不足：

▲

一是規范的涉及范圍：Device Tree 的規范[11]只涉及如何使用 DTS（Device Tree Source）語言來描述硬件信息，而 ACPI 規范涉及的范圍更廣：除了如何使用 ASL 語言描述硬件信息，ACPI 規范還規定了操作系統如何與底層固件、硬件交互的很多要求。這些規范的約束，是實現 “一個通用操作系統可運行在不同機器上” 的必要條件之一。

▲

二是靈活性：ASL 語法上更加靈活，如下面的例子，它支持變量賦值、流程控制等運算符，可以讓固件在無需修改操作系統的情況下，實現更加靈活的行為：

DefinitionBlock ("","DSDT",2,"","",0x0){ Name (INT1,0x02) Method (CTDW,1) { local0= arg0 while(local0) { printf("%o",local0) local0-- } } Method (CTUP,1) { local0= arg0 while(local0

因此，目前 Device Tree 有的，ACPI 有；Device Tree 沒有的，ACPI 也有。并且在 ACPI 已經是個人電腦/服務器領域生態標準的前提下，要擴展 Device Tree 讓它成為一個并沒有明顯優于 ACPI 的新標準，成為一件費力又不討好的事情。自然而然地，在嵌入式領域使用更加輕量的 Device Tree，在個人電腦/服務器領域使用更符合行業生態標準的 ACPI，是更加合適的選擇。

ARM 的選擇

嵌入式領域高度定制化的產品特點，難以形成行業內通用的標準。在面對個人電腦/服務器這些有著幾十年歷史、涉及諸多零部件廠商、并且相互間遵循一定行業標準的 x86 傳統生態領域時，ARM 嵌入式領域常用的 U-Boot、Device Tree 等技術方案也難以施展拳腳。那么 ARM 的選擇自然不言而喻：在個人電腦/服務器也全面擁抱起了 x86 常用的 UEFI、ACPI、SMBIOS 等標準。

對此，ARM 于 2020 年發布了Arm SystemReady標準，對不同產品的軟、硬件做出規范要求：

ARM SystemReady 對不同產品的要求。取自 arm-systemready-whitepaper.pdf[12]

在 2024 年 11 月 21 日發布的 Arm SystemReady Requirements Specification v3.0[13]中，ARM 調整了 SystemReady 的分類：

SystemReady LS 被棄用

SystemReady ES 和 SR 統稱為新的 “SystemReady”，用于那些可運行一個無需定制化修改的、通用的操作系統的產品，它要求 ACPI 是必須實現的。

SystemReady IR 則改名為 “SystemReady Devicetree”，用于那些運行嵌入式 Linux/BSD 操作系統的產品。

取自 Arm SystemReady Requirements Specification v3.0[13]

可見，對于個人電腦/服務器領域，ACPI 是十分重要的，它是實現操作系統通用化不可或缺的一環。

Hardware-reduced ACPI

ACPI 誕生于 x86 架構，它的規范中也規定了需在硬件上實現的 ACPI 寄存器組，這些寄存器跟 x86 自然有著千絲萬縷的關系。但 ARM/RISC-V 硬件上不一定實現有這些寄存器，那它們要如何支持 ACPI 呢？

ACPI 規范 v5.0 引入了一種新的方法，稱為hardware-reduced ACPI，它不再要求必須實現以下這些 ACPI 硬件特性[14]：

Power Management (PM) timer

Real Time Clock (RTC) wake alarm

System Control Interrupt (SCI)

Fixed Hardware register set (PMx_* event/control/status registers)

GPE block registers (GPEx_* event/control/status registers)

Embedded controller

相對應地，某些功能有了替代的實現手法。例如 ACPI 的事件通知模型，在傳統 x86 上它是通過 SCI（System Control Interrupt）中斷和 GPE（General-Purpose Event）寄存器實現，由 SCI 中斷來觸發 ACPI 事件的產生；而在 hardware-reduced ACPI 中，則變成可通過 GPIO-signaled ACPI Events 或 Interrupt-signaled ACPI Events 這兩種機制實現，前者是由 GPIO 中斷來觸發 ACPI 事件，后者則可由任意中斷來觸發 ACPI 事件。

ACPI 電源管理

ACPI 電源管理相關狀態分類

關于電源管理，ACPI 規范中為系統以及設備定義了以下狀態（state）：

取自 ACPI specification v6.6[2]

▲

系統的全局狀態Gx（Global System State）與睡眠狀態 Sx（Sleeping State）：

G0（S0）- Working：正常工作狀態。

G1 - Sleeping：以較低功耗運行的狀態。從用戶角度 “看起來” 系統像是關閉的，但無需重啟操作系統就可回到 G0/S0 狀態。G1 又細分為 S1~S4 四種傳統狀態，以及一種相對較近新提出的 S0ix 狀態：

S1 - POS（Power on Suspend）：最耗電的睡眠狀態。該狀態下會維持 CPU 和內存的供電，操作系統的上下文不會丟失。

S2：一種比 S1 更深的睡眠狀態。該狀態下 CPU 會斷電。

S3 - STR（Suspend to RAM）/ Standby / Sleep：該狀態下只有內存被供電，除了內存外的其他上下文都不會保留。

S4 - STD（Suspend to Disk）/ Hibernation / Non-Volatile Sleep：該狀態允許主板斷電，操作系統會將上下文保存在非易失存儲介質（Non-Volatile Storage）中。

S0ix- 該狀態有多種名稱：ACPI 規范中稱之為Low Power S0 Idle[2]，英特爾稱之為S0ix[15]，微軟稱之為Modern Standby[16]，Linux 內核稱之為Suspend o Idle 或 S2Idle[17]該睡眠狀態的功耗接近甚至低于傳統的S3 狀態，并且能更快地恢復到 G0/S0 狀態。該狀態還可以繼續細分為 S0i1、S0i2、S0i3 等子狀態。

G2（S5）- Soft Off：以最低功耗運行的狀態。硬件不保留操作系統的上下文，操作系統經重啟后才能回到 G0/S0 狀態。該狀態下并不一定能安全地移除硬件。

G3 - Mechanical Off：機械上的斷電狀態。不保留硬件上下文，可安全移除硬件。操作系統經重啟后才能回到 G0/S0 狀態。該狀態下除了 RTC（real-time clock）外，功耗為零。

Legacy：如果系統不支持 ACPI，則運行在該狀態。該狀態下的電源管理通過 APM、Legacy PnP 等規范實現。

▲

設備的電源狀態Dx（Device Power State）：系統處于 G0/S0 狀態時，設備可在以下電源狀態之間切換（設備不一定會實現所有這些電源狀態，實現的狀態多寡會視設備類別而有所不同）：

D0 - Fully-On：功耗最高的狀態。設備完全活躍并能持續保持所有相關上下文。

D1：其含義視設備類別而定。通常會被定義為相比 D2 功耗更高、保留的上下文更多的狀態。很多設備都沒有定義該狀態。

D2：其含義視設備類別而定。通常會被定義為相比 D1 或 D0 功耗更低、保留的上下文更少的狀態。很多設備都沒有定義該狀態。

D3hot：其含義視設備類別而定。通常會被定義為在不影響設備枚舉的情況下功耗盡可能低的狀態。

D3（D3cold）- Off：設備完全斷電。該設備所有上下文都會丟失。在軟件上無法被枚舉到。

▲

CPU 的電源狀態Cx（Processor Power State）：系統處于 G0/S0 狀態時，CPU 可在以下電源狀態之間切換：

C0：該狀態下 CPU 會正常執行指令。

C1 - Halt：擁有最短喚醒延遲的狀態。該狀態下 CPU 不執行指令。

C2 - Stop Clock：比 C1 功耗更低，但喚醒延遲更長。該狀態下 CPU 不執行指令。

C3 - Sleep：比 C2 功耗更低，但喚醒延遲更長。該狀態下 CPU 不執行指令。

▲

CPU 或設備的性能狀態Px（Device and Processor Performance State）：當 CPU 或設備處于活躍狀態時（C0/D0），可處于以下不同的性能狀態：

P0：性能最高，功耗最大。

P1 ~ Pn：隨著 n 增大，性能降低，功耗也降低。n 的大小視實際 CPU 和設備而定，最大不超過 255。

Hardware-reduced ACPI 的電源管理實現

系統級睡眠狀態 Sx

傳統 x86 ACPI 會借助硬件寄存器來實現 Sx 狀態切換，而對于使用 hardware-reduced ACPI 的 ARM/RISC-V，通常也不與 x86 的 ACPI 方法兼容。但所幸，它們都定義有架構內通用的規范接口，并且也可使用 UEFI 的一些標準接口：

▲

UEFI runtime service（運行時服務）ResetSystem()可供操作系統調用來實現重啟或關機的功能，從而實現 G0/S0 與 G2/S5 狀態間的切換。通過 UEFI runtime service，與硬件平臺相關的寄存器操作被下放到 UEFI 或更底層的固件中，對操作系統不可見，操作系統只需調用 UEFI 的標準接口即可實現重啟和關機的功能。

▲

ARM 定義有SCMI（System Control and Management Interface）規范，可提供一套標準接口用于電源、性能以及系統管理[18]，從而實現 Sx 狀態的切換。

▲

RISC-V 定義 SBI（Supervisor Binary Interface）規范[19]，通過以下這些標準接口可實現 Sx 狀態的切換：

SBISRST（System Reset）Extension：可用于實現重啟/關機功能。

SBISUSP（System Suspend）Extension：可用于實現休眠功能。

設備電源狀態 Dx

設備的 Dx 電源狀態不涉及 ACPI 硬件寄存器，ARM/RISC-V 也與 x86 相同，通過 ACPI 規范中定義的 ASL 對象（object）來實現，具體包含以下這些：

取自 ACPI specification v6.6[2]

取自 ACPI specification v6.6[2]

CPU 電源狀態 Cx 與性能狀態 Px

對于 CPU 的電源狀態 Cx 與性能狀態 Px，ACPI 規范中均提供了方法供實現 hardware-reduced ACPI 的平臺使用：

▲

LPI（Low Power Idle）States機制：結合 FFH 規范，通過該指令集架構平臺自身的方法實現 CPU 的 Cx 狀態控制。

▲

CPPC（Collaborative Processor Performance Control）機制：結合 FFH 規范，通過協處理器對主處理器的 Px 狀態進行控制。

LPI States 和 CPPC 兩套機制都要結合FFH（Functional Fixed Hardware）規范使用，FFH 規范讓 ACPI 規范可以對接到各指令集架構平臺自身內部的、架構間各異的一些實現方法。x86/ARM/RISC-V 都分別定義有自己的 FFH 規范[20][21][22]。

例如 RISC-V，FFH 最終會對接到 SBI 擴展的實現中：

▲

Cx 狀態的控制由 “ACPI LPI States 機制 + RISC-V FFH 規范 + RISC-V SBI HSM（Hart State Management）Extension” 實現。

▲

Px 狀態的控制由 “ACPI CPPC 機制 + RISC-V FFH 規范 + RISC-V SBI CPPC Extension” 實現。

RISC-V ACPI 的相關規范

借 ARM 的 “他山之石”，RISC-V 社區早早地認識到了在個人電腦/服務器領域對接生態標準的重要性，因此十分積極地制定了一些相關規范，其中涉及 ACPI 的有：

▲

RISC-V BRS（Boot and Runtime Services）Specification[23]：分別為通用系統和定制化系統提出了BRS-I（Interoperable）和BRS-B（Bespoke）兩套標準，定義了它們在設備發現、系統管理等方面的軟件要求（類似于 ARM 的 “SystemReady” 和 “SystemReady Devicetree”），其中也包括對 RISC-V ACPI 的一些新增定義與實現要求：

為 RISC-V 新增的 ACPI ID。取自 RISC-V BRS specification v0.91[23]

RISC-V 必須實現的 ACPI 表。取自 RISC-V BRS specification v0.91[23]

RISC-V 可按需實現的 ACPI 表。取自 RISC-V BRS specification v0.91[23]

▲

ACPI 規范中一些原有內容也增加 RISC-V 的支持，例如新增了描述 RISC-V Hart 能力的RHCT（RISC-V Hart Capabilities Table），在MADT（Multiple APIC Description Table）中增加描述 RISC-V 中斷控制器 AIA 和 PLIC 的結構，等等：

ACPI v6.6 的改動（截圖中并沒有囊括所有），其中包含很多 RISC-V 內容。取自 ACPI specification v6.6[2]

▲

RIMT（RISC-V IO Mapping Table）Specification[24]：定義了描述 RISC-V IOMMU 信息的 ACPI 表的規范。

▲

RISC-V FFH（Functional Fixed Hardware）Specification[22]：定義了 RISC-V 的 ACPI FFH 規范，供 ACPI 的 LPI States 機制和 CPPC 機制使用，實現對 CPU Cx 狀態和 Px 狀態的控制。

進迭時空芯片對 ACPI 的支持

目前進迭時空已經量產的 8 核 64 位 RISC-V AI CPU 芯片 K1，已經基于開源的 Tianocore EDK II[6]，完成了對 UEFI 的適配，預計在不遠的將來也會加入 ACPI 的支持，在終端領域適配更加通用、開放的生態。

另外進迭時空正在研發中的服務器芯片平臺，基于自研的 X100 高性能處理器核，完整支持虛擬化、安全、RAS 等服務器特性，符合 RISC-V Server SoC Specification v1.0[25]規范的要求，目前也已經完成了 UEFI + ACPI 的適配，可基于 ACPI 啟動 Linux 內核：

進迭時空服務器芯片平臺 Linux 內核啟動日志

結語

RISC-V 因 “開放” 的優勢而發展迅猛，但 “碎片化” 的烏云也一直籠罩在其上空。為此 RISC-V 社區制定了各種軟、硬件規范，也接受了源自于 x86 的 ACPI，讓碎片化問題逐步得以改善。相信在不遠將來的某一天，RISC-V 也能像 x86 那樣，只需一個操作系統鏡像就可在不同的機器上運行。