1 介紹

本文主要是在ARM架構(gòu)的不同異常等級上工作的軟件之間，提供一個標準的電源管理接口。這些軟件，比如Linux、Hypervisor、安全Firmware和可信OS之間必須能夠?qū)崿F(xiàn)互相操作。而這些軟件可能由不同廠商提供，本標準就是為這些軟件的集成提供便利。

這些PSCI接口有利于電源管理代碼通用化、模塊化：

CPU核的空閑管理

CPU核的動態(tài)添加、刪除，以及輔核引導(dǎo)

系統(tǒng)關(guān)機和復(fù)位

該接口規(guī)范不會包含動態(tài)電壓頻率調(diào)節(jié)(DVFS)或設(shè)備電源管理(比如，GPU等外設(shè)的管理).

該接口規(guī)范設(shè)計用來與硬件探測技術(shù)（如ACPI和FDT）等配合使用，并不是要取代ACPI或FDT。

本文描述了PSCI版本1.1,1.0和0.2。對于0.2，還提供了一個勘誤更新。

本文包含以下內(nèi)容：

第1章 提供介紹和文檔引用

第2-4章 提供背景知識，包括：

PSCI的設(shè)計目的

電源狀態(tài)術(shù)語的定義

發(fā)送PSCI請求的方法

ARM架構(gòu)知識

第5章 提供PSCI功能的主要描述

第6章 提供PSCI功能的實現(xiàn)細節(jié)

第7-8章 提供PSCI規(guī)范的修訂歷史和術(shù)語表

1.1 ARM官方文檔

下面這些文檔包含與本文檔相關(guān)的信息：

[1] ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition (ARM DDI 0406).

[2] Embedded Trace Macrocell Architecture Specification (ARM IHI 0014).

[3] Program Flow Trace Architecture Specification (ARM IHI 0035).

[4] SMC調(diào)用約定(ARM DEN 0028).

[5] ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile (ARM DDI 0487).

[6] ACPI規(guī)范.

[7] PSCI設(shè)備樹定義.

[8] ARM可信固件（ATF）.

[9] Power Control System Architecture Specification (ARM DEN 0050).

2 背景知識

支持電源管理的操作系統(tǒng)，能夠動態(tài)改變CPU核的電源狀態(tài)，根據(jù)進行負載均衡，努力降低功耗。電源管理技術(shù)主要分為兩類：

空閑管理：當在某個核上，OS的內(nèi)核沒有線程可以調(diào)度時，可以將該核置于clock-gated、retention、power-gated狀態(tài)。但是，該核對于OS而言還是可用的。

Hotplug熱插拔：根據(jù)對算力的需求變化，而將CPU核置于離線、在線。離線時，OS負責(zé)將所有中斷和線程從核上遷移走；當在線時，OS負責(zé)重新進行負載均衡。

盡管由單個供應(yīng)商提供嵌入式系統(tǒng)的軟件可能更簡單，但事實并非如此。為了安全，ARM將硬件架構(gòu)劃分為4個不同的異常級(EL)以及2個安全狀態(tài)，以便支持不同特權(quán)的軟件分區(qū)。

下表是基于ARM架構(gòu)的硬件平臺上的軟件劃分：

AArch32	AArch64	軟件和供應(yīng)商
NS_EL0 (PL0)	NS_EL0	非特權(quán)應(yīng)用，如APP
NS_EL1 (PL1)	NS_EL1	富操作系統(tǒng)內(nèi)核，如Linux、Windows、iOS
NS_EL2 (PL2)	NS_EL2	Hypervisor（Citrix、VMWare、OK-Labs）
S_EL0 (PL0)	S_EL0	可信OS的應(yīng)用
S_EL3 (PL1)	S_EL1	可信OS的內(nèi)核（Trustonic）
S_EL3 (PL1)	S_EL3	安全Monitor，執(zhí)行安全固件（ATF）

AArch32是ARMv8架構(gòu)的32位執(zhí)行狀態(tài)，在ARMv8架構(gòu)之前采用的執(zhí)行狀態(tài)。在ARMv7處理器中，異常級的概念是隱含的，相關(guān)文檔也并未說明。那時候，虛擬化擴展提供EL2功能，安全擴展提供EL3功能，安全狀態(tài)由特權(quán)級（PL-Privilege Level）標識異常的層次結(jié)構(gòu)。更多信息，參考第3.2節(jié)。

因為不同供應(yīng)商的不同操作系統(tǒng)都可運行在ARM系統(tǒng)上，電源管理就需要一個協(xié)作的方法?？紤]到運行在EL1上的類OS軟件或運行在EL2上的hypervisor軟件，一般處于非安全狀態(tài)，如果想要進入idle狀態(tài)、給一個核上電或掉電、或復(fù)位或關(guān)閉系統(tǒng)，更高異常級的監(jiān)控軟件必須能夠響應(yīng)這種電源狀態(tài)變化的請求。

同樣，如果某個wakeup事件改變了核的電源狀態(tài)，那么這些監(jiān)管軟件需要執(zhí)行諸如恢復(fù)上下文之類的操作。PSCI提供了不同監(jiān)管軟件之間互操作和集成的標準接口定義。本文檔會詳細描述這類接口，以及在idle、hotplug、shutdown和reset情況下如何使用它們。

3 假設(shè)和建議

本文檔定義了在不同監(jiān)管軟件之間協(xié)調(diào)電源管理的API。這種API允許監(jiān)管軟件請求給核上電、掉電，安全上下文的核間遷移（可信OS需要）。本文中，假設(shè)EL2和EL3都已經(jīng)實現(xiàn)。

3.1 PSCI用途

PSCI具有下面的用途：

提供給監(jiān)控程序通用接口，可以在下列情況時，管理功耗：

CPU核的空閑管理；

系統(tǒng)中的CPU核動態(tài)添加和刪除，也稱之為hotplug熱插拔；

其它輔核的啟動；

將受信任的操作系統(tǒng)上下文從一個核遷移到另一個核；

系統(tǒng)關(guān)機和復(fù)位。

提供給監(jiān)控管理程序通用接口，結(jié)合FDT和ACPI描述去支持電源管理代碼的泛化。

PSCI不包括：外設(shè)電源管理 和 動態(tài)電壓和頻率調(diào)節(jié)（DVFS）。

PSCI不提供給監(jiān)控軟件電源狀態(tài)表示。但是，可以和ACPI或FDT等硬件描述技術(shù)結(jié)合使用。

3.2 異常級別、ARMv7特權(quán)級別和最高特權(quán)級別

ARMv8架構(gòu)明確提出了EL的概念，也定義了安全狀態(tài)下軟件執(zhí)行特權(quán)的層次結(jié)構(gòu)。

ARMv7架構(gòu)中，EL概念是隱含在架構(gòu)體系中的：

虛擬化擴展提供了EL2的功能（只存在非安全狀態(tài)下）。

安全擴展提供了EL3功能，包含對兩種安全狀態(tài)的支持?？刂剖窃贛onitor模式下完成的，該模式也只存在于安全狀態(tài)下。

ARMv7使用PL（特權(quán)級）的概念描述軟件執(zhí)行的特權(quán)層級結(jié)構(gòu)。因為Monitor模式的存在，ARMv7的非安全狀態(tài)和安全狀態(tài)是非對稱的，如下所述：

非安全狀態(tài)，特權(quán)層次結(jié)構(gòu)是：

PL0, 非特權(quán)，適用于User模式

PL1, OS級特權(quán)，適用于System, FIQ, IRQ, Supervisor, Abort和Undefined模式

PL2, hypervisor特權(quán)，適用于Hyp模式

安全狀態(tài)，特權(quán)層次結(jié)構(gòu)是：

Secure PL0, 非特權(quán)，僅適用于User模式

Secure PL1, 可信OS和Monitor級特權(quán)，適用于System, FIQ, IRQ, Supervisor, Abort, Undefined和Monitor模式

AArch32執(zhí)行狀態(tài)下，異常級和之前的運行模式對應(yīng)關(guān)系如下：

非安全狀態(tài)：

EL0: User 模式

EL1: System, FIQ, IRQ, Supervisor, Abort和Undefined模式

EL2: Hyp模式

安全狀態(tài)：

Secure EL0: User 模式

EL3: System, FIQ, IRQ, Supervisor, Abort, Undefined和Monitor模式

本文檔中如果不特殊聲明，則使用異常級別（EL）的術(shù)語：

通常情況下，提及的EL1和EL0就是指非安全EL1和EL0，除非有特殊說明；

3.3 ARM架構(gòu)上的軟件棧

ARM設(shè)備上可能有的軟件棧，如下所示：

如圖所示，非安全空間中的擁有特權(quán)的代碼：

Rich-OS內(nèi)核：比如，Linux或Windows，運行在非安全EL1。如果運行在Hypervisor之上，則Rich-OS內(nèi)核作為hypervisor的一個客戶機運行。

Hypervisor：運行在EL2，只有非安全狀態(tài)（新ARMv8架構(gòu)中，已經(jīng)存在安全狀態(tài)的hypervisor）。

安全空間中擁有特權(quán)的代碼：

安全平臺固件(SPF):

芯片或OEM廠商提供。也是系統(tǒng)啟動階段，運行的第一段程序。它提供的服務(wù)有，平臺初始化、可信OS的安裝、SMC調(diào)用的調(diào)度執(zhí)行。有些調(diào)用的目標可能是SPF，另一些則可能是可信OS。SPF可以運行在EL3，也可以運行在安全EL1（但是，條件是EL3運行在AArch64狀態(tài)）。ARM提供了一個開源的可信固件代碼。

可信OS:

為normal空間提供安全服務(wù)，即為安全應(yīng)用提供一個運行時環(huán)境。在AArch32狀態(tài)下，可信OS運行在安全EL3，如果是AArch64狀態(tài)，運行在EL1。

PSCI規(guī)范主要關(guān)注安全、非安全世界之間的電源管理接口。它提供了發(fā)送電源管理請求的方法。所以，為了處理這些請求，SPF必須包含PSCI實現(xiàn)。

另外，PSCI實現(xiàn)也可能需要在SPF和可信OS之間建立通信。當然，它們之間的處理根據(jù)廠商不同而有所不同。

盡管，PSCI主要關(guān)注安全和非安全世界之間的電源管理請求，但是，也可以在Rich OS和hypervisor之間使用。

3.4 通道

在不同的異常級別之間提供可以傳送消息的通道（一般使用SMC異常指令實現(xiàn)），這樣才能提供相同的PSCI電源管理接口。具體參考SMCCC。

3.5 安全軟件和電源管理

許多可信OS不支持SMP。即使在多核平臺上，也是運行在某個指定的核上。所以，期望發(fā)起SMC調(diào)用的核與可信OS運行的核是同一個。不支持多核，可以保證可信OS小而美，容易通過功能安全認證。

基于ARM架構(gòu)的系統(tǒng)通常會包含一個電源控制器，或者電源管理電路，以便管理CPU核的電源。它會提供許多電源管理功能，比如將核、簇或者集群轉(zhuǎn)變?yōu)榈凸臓顟B(tài)。在低功耗狀態(tài)，核可以完全關(guān)掉，也可以不執(zhí)行代碼而處于靜默狀態(tài)。ARM 強烈推薦由安全空間控制電源狀態(tài)的變化。否則，在進入低功耗狀態(tài)之前，不能清除安全狀態(tài)（包括安全cache的清零）。其它的電源管理，比如動態(tài)電源性能管理（通過調(diào)節(jié)電壓和頻率實現(xiàn)）不在本接口規(guī)范的范圍內(nèi)。

3.6 虛擬化和CPU核電源管理策略

虛擬機可以分為兩種類型

Type-1: 有時候稱為 native 或 bare metal。通俗理解的話，就是hypervisor代碼直接接管硬件，對上提供統(tǒng)一的虛擬隔離空間。所以，Guest OS看到的都是虛擬設(shè)備。

Type-2: 有時候稱為hosted，或者托管類型hypervisor。這類虛擬程序需要依賴一個主機OS，作為宿主。該Host OS看到的是真實硬件，但是Guest OS看到的是虛擬設(shè)備。

這是一個泛泛的分類，可能會有許多變種。ARMv8架構(gòu)允許在EL1或EL2運行一個Type-2類型的hypervisor，這更加模糊了類型-1和類型-2的差異。但是，對于電源管理來說，不論哪種類型的hypervisor，都需要捕獲這種PSCI調(diào)用。

從電源管理和虛擬化的角度來看的話，有兩種類型的OSPM：

物理OSPM: 這個概念包含管理物理電源狀態(tài)的軟件。

虛擬OSPM: 這是存在于虛擬機的Guest OS中的OSPM，它管理的是虛擬的，而不是物理電源狀態(tài)。

對于type-2 hypervisor，物理OSPM存在于主機OS中。電源管理策略由運行在EL1的Rich OS負責(zé)管理。物理OSPM就包含在這種Rich OS中。在該層，直接擁有物理核的視角。下圖的左邊部分就是示例。

對于本文涉及的電源管理，type-2 hypervisor的行為取決于調(diào)用者。如果調(diào)用者是Host OS，hypervisor允許調(diào)用直接穿透到安全平臺固件（SPF）。在這種情況下，hypervisor只需執(zhí)行必要的操作，比如保存powerdown時的狀態(tài)。然后，使用調(diào)用者傳遞過來的參數(shù)調(diào)用SPF。如果沒有特殊操作，hypervisor甚至不會捕獲來自Host OS的調(diào)用，直接將其路由給SPF。Guest OS使用虛擬OSPM，也是通過PSCI API發(fā)出電源管理請求，但是發(fā)送的目標是虛擬核和虛擬電源狀態(tài)。hypervisor會捕獲這些請求，然后將其發(fā)送到物理OSPM。然后，由物理OSPM決定是否請求真實的物理電源管理。對于虛擬機來說，電源管理到hypervisor就結(jié)束了。

對于type-1 hypervisor，電源管理策略通常是hypervisor自身管理的。如上圖右半部分所示。hypervisor實現(xiàn)物理OSPM模塊。這種情況下，虛擬機擁有的是虛擬核。由hypervisor決定虛擬機的虛擬電源狀態(tài)是否請求物理電源控制，如果需要，則使用PSCI API調(diào)用安全平臺固件SPF。同樣，Guest OS也使用PSCI API接口將虛擬電源管理請求發(fā)送給hypervisor。對于虛擬機來說，電源管理到hypervisor就結(jié)束了。

在某些情況下，type-1 hypervisor委托一個特權(quán)Guest OS管理電源。這種情況下，物理OSPM在特權(quán)Guest OS中實現(xiàn)。大概的電源管理方法與type-2 hypervisor類似。

4 PSCI使用場景和要求

4.1 空閑管理

當一個核處于idle狀態(tài)時，OSPM將其置于低功耗狀態(tài)。通常，選擇進入不同的電源狀態(tài)，會有不同的entry和exit延遲，也會有不同的功耗。想要進入哪種電源狀態(tài)，依賴于核重新工作的時間。除了核之外，電源狀態(tài)也可能依賴于SoC中的其它組件的活動。每種狀態(tài)都由一組組件的狀態(tài)共同決定，進入該狀態(tài)時，這些組件通過時鐘控制（clock-gated）或電源控制（power-gated）。這些狀態(tài)有時候也描述為淺睡眠或深度睡眠。通常，文獻描述使用X標識深度睡眠，Y標識淺睡眠：

X狀態(tài)應(yīng)該是Y狀態(tài)的超集。

X狀態(tài)比Y狀態(tài)更省電。

從低功耗狀態(tài)進入運行狀態(tài)所需要的時間稱為喚醒延遲。通常，深度睡眠狀態(tài)具有更長的喚醒延遲。

盡管空閑電源管理是由核上的線程行為引起的，但是OSPM將硬件平臺設(shè)置的狀態(tài)，也可能會影響除CPU核之外的其它組件。比如，如果SoC中的最后一個核進入idle狀態(tài)，OSPM就可以考慮整個SoC的電源狀態(tài)了。此時的選擇也會受系統(tǒng)中的其它組件影響，所以，應(yīng)該在SPF、hypervisor、OS之間協(xié)調(diào)電源管理。典型的例子是，當所有核，和其它請求者都處于空閑狀態(tài)時，將系統(tǒng)置于一種狀態(tài)，在這種狀態(tài)下，將上下文保存在內(nèi)存中（內(nèi)存不斷刷新中）。OSPM必須提供必要的電源管理軟件基礎(chǔ)設(shè)施，確定能夠?qū)﹄娫礌顟B(tài)作出正確的選擇。

在空閑管理中，當一個核被置于低功耗狀態(tài)，它可能隨時被喚醒事件激活，比如說中斷。

ARM架構(gòu)劃分的電源狀態(tài)有四種：

Run

CPU核上電，且可以正常運行的狀態(tài)。

Standby

CPU核上電。通過WFI或WFE指令進入該狀態(tài)，由喚醒事件喚醒。此過程中，CPU核保持所有狀態(tài)。也就是說，從standby到run狀態(tài)，不會復(fù)位CPU核。CPU核的上下文都會被保持，喚醒即可訪問這些內(nèi)容。處于該核所在電源域的外部調(diào)試器（debugger），能夠訪問debug寄存器。換句話說，standby狀態(tài)不會影響調(diào)試器的使用。

Retention

CPU核的狀態(tài)，包括debug設(shè)置等，保存在低功耗的保持寄存器中，這樣允許CPU核至少可以關(guān)閉部分電源。從低功耗狀態(tài)到運行態(tài)的轉(zhuǎn)變，不用復(fù)位CPU核。低功耗轉(zhuǎn)變到運行態(tài)時，原先保存的狀態(tài)數(shù)據(jù)從保持寄存器中恢復(fù)。所以，從OS的角度來說，Retention和Standby狀態(tài)沒有什么差別，除了恢復(fù)時的入口地址，延遲和使用上的一些限制之外。但是，對于外部debugger來說，就不一樣了，外部debug請求事件會被掛起，debug寄存器無法訪問。

Powerdown

該狀態(tài)下，CPU核會被掉電。軟件需要保存所有的核狀態(tài)數(shù)據(jù)。從掉電到恢復(fù)運行，需要：

上電后，需要復(fù)位CPU核

恢復(fù)之前保存的核的狀態(tài)數(shù)據(jù)

Powerdown狀態(tài)對上下文是破壞性的。不僅僅是CPU核的狀態(tài)數(shù)據(jù)，如果是更深的休眠狀態(tài)，可能包括GIC或者平臺依賴的其它一些IP核也會掉電。所以，相關(guān)數(shù)據(jù)或狀態(tài)必須保存。根據(jù)debug和trace電源域的組織架構(gòu)，其上下文內(nèi)容也有可能會丟失。所以，OS必須提供保存和恢復(fù)這些內(nèi)容的機制。

對于OS來說，standby和retention都是一樣的，除了debugger之外。所以，后面我們使用standby代表這兩種狀態(tài)。

ARM期望在具有最高特權(quán)的異常級別上，實現(xiàn)管理電源控制器的代碼（通常就是ATF）。那么就必須提供接口，以便OSPM將CPU核置于低功耗狀態(tài)的消息事件，從不同的異常級層層往下傳遞（假設(shè)越往下，異常級別越高）。而PSCI就是這樣的一種機制，將OSPM的電源請求傳遞給下一個異常級EL。

對于standby狀態(tài)，直接使用WFI或WFE指令即可進入。但是，更深層的standby或retention狀態(tài)，則要求對電源控制器進行編程，而PSCI僅提供訪問電源控制器的接口，并隱藏了與平臺相關(guān)的代碼。

對于Powerdown狀態(tài)，則要求提供每一級EL下保存和恢復(fù)上下文的接口。而且，對于Powerdown狀態(tài)還要求一個return地址。這地址是被喚醒時，OS期望的開始運行的地方。對于Powerdown狀態(tài)，CPU核從reset復(fù)位向量（安全狀態(tài)）開始運行。待完成初始化，則跳轉(zhuǎn)到Powerdown之前要求的那個返回地址處開始執(zhí)行。PSCI提供了傳遞返回地址和上下文的參數(shù)。

4.2 電源狀態(tài)系統(tǒng)拓撲

多核系統(tǒng)中，不同的電源域控制系統(tǒng)的不同部分。每一個電源域可能是一個或多個PE（CPU核、協(xié)處理器、GPU），內(nèi)存（Cache、DRAM），簇內(nèi)、簇間一致性部件等組成。

電源域中的每個組件的電源狀態(tài)，都可以影響電源域中的其它組件。雖然，從物理上來說，電源域不是一個必須存在的層次結(jié)構(gòu)。但是，從軟件的角度來說，必須進行一個邏輯上的劃分。如果想要改變電源域的電源狀態(tài)，必須對其依賴項進行排序。比如，共享Cache的電源域，以及使用共享Cache的CPU核的電源域，它們之間的依賴關(guān)系。在這樣一個系統(tǒng)中，為了保證數(shù)據(jù)的一致性，必須先關(guān)閉CPU核的電源，然后再關(guān)閉共享Cache的電源。

上圖展示了一個系統(tǒng)級的電源域的拓撲結(jié)構(gòu)的示例。它擁有兩個子電源域，每一個包含一個cluster簇，支持一組cluster電源狀態(tài)。每一個cluster電源域，又包含兩個子電源域，每一個包含一個CPU核，并額外支持一個電源狀態(tài)。

從硬件的角度來看，一個系統(tǒng)被劃分為多個單獨或共享的電源域。每個電源域都可以表示為電源域拓撲樹中的一個節(jié)點。兄弟電源域是互斥的。父電源域由子電源域共享。樹中的各種級別(示例中的核、cluster簇和系統(tǒng))稱為電源級別。較高的級別，更接近樹的根(系統(tǒng))，較低的級別更接近樹葉(核)。

4.2.1 局部電源狀態(tài)和組合電源狀態(tài)

上面拓撲結(jié)構(gòu)中的各個節(jié)點都有自己的電源狀態(tài)，我們稱為局部電源狀態(tài)。當處于空閑核上的OS請求電源狀態(tài)的改變時，不僅需要請求改變CPU核的局部電源狀態(tài)，還需要請求改變父節(jié)點的電源狀態(tài)。比如，上圖的示例中，假設(shè)核1是簇0內(nèi)最后進入空閑狀態(tài)的，對于OS來說，就需要同時為簇0和核1請求電源狀態(tài)改變。這種組合的電源狀態(tài)我們就稱為組合電源狀態(tài)。這種組合電源狀態(tài)可不是隨意組合的，而是電源等級越高的節(jié)點上，其電源狀態(tài)越淺。換句話說，子節(jié)點進入休眠的程度應(yīng)該大于等于父節(jié)點。規(guī)則如下：

電源等級高的節(jié)點掉電（Powerdown)，電源等級低的節(jié)點也必須掉電；

電源等級高的節(jié)點保持（Retention)，電源等級低的節(jié)點只能是保持或掉電；

電源等級高的節(jié)點待機（Standby)，電源等級低的節(jié)點只能是待機、保持或掉電；

電源等級高的節(jié)點運行（Run)，電源等級低的節(jié)點可以是任意狀態(tài)。

如下表所示：

系統(tǒng)級	簇級	核級
Run	Run	Standby
Run	Run	Retention
Run	Run	Powerdown
Run	Retention	Retention
Run	Retention	Powerdown
Run	Powerdown	Powerdown
Retention	Retention	Retention
Retention	Retention	Powerdown
Retention	Powerdown	Powerdown
Powerdown	Powerdown	Powerdown

4.2.2 親和力的層次結(jié)構(gòu)

ARM系統(tǒng)通常是多核、或多簇的處理器。本文檔使用親和力的層次結(jié)構(gòu)描述CPU核和簇的架構(gòu)關(guān)系。親和力層次結(jié)構(gòu)往往直接對應(yīng)系統(tǒng)的電源拓撲，但這也不是絕對的。

4.2.3 電源狀態(tài)協(xié)調(diào)

高層的節(jié)點進入某種局部電源狀態(tài)，必須與子節(jié)點的電源狀態(tài)進行協(xié)調(diào)。比如說，想要使一個簇（cluster）進入Powerdown狀態(tài)，那么該簇內(nèi)所有的核也必須進入Powerdown狀態(tài)。實現(xiàn)方式就是，其它核都進入Powerdown狀態(tài)，最后一個核再把自己和簇置于Powerdown狀態(tài)。

對于這種對子節(jié)點的電源狀態(tài)進行協(xié)調(diào)的方式，PSCI支持兩種：平臺協(xié)調(diào)模式、OS發(fā)起模式。

平臺協(xié)調(diào)模式

這是默認的電源協(xié)調(diào)模式。在該模式下，PSCI實現(xiàn)者（如ATF等）負責(zé)協(xié)調(diào)電源狀態(tài)。當某個核上沒有任務(wù)時，OSPM為該核、以及所在簇請求允許范圍內(nèi)的最深休眠狀態(tài)。因為該核的電源狀態(tài)改變請求，可能影響其父節(jié)點，所以，PSCI實現(xiàn)者得根據(jù)簇內(nèi)所有節(jié)點的情況選擇最深的休眠狀態(tài)。實際上，電源狀態(tài)請求表達了兩種限制：

PSCI實現(xiàn)就會根據(jù)這兩個限制，為指定的節(jié)點內(nèi)所有核，選擇一個最深的電源狀態(tài)。下表展示了OSPM請求不同的電源組合狀態(tài)，而PSCI最終能夠響應(yīng)的狀態(tài)。假設(shè)簇1一直處于掉電狀態(tài)中。

通常情況下，電源狀態(tài)越深，喚醒延遲越長。所以，我們假設(shè)保持狀態(tài)比掉電狀態(tài)具有更短的喚醒延遲。但是，事實并非如此。根據(jù)第2個限制，PSCI實現(xiàn)者必須滿足每個核喚醒時間的請求。假設(shè)雙核系統(tǒng)，具有3層系統(tǒng)狀態(tài)，狀態(tài)A、B、C，電源休眠程度A < B < C，而喚醒延遲則是A < C < B。如果核0選擇狀態(tài)B，而核1選擇狀態(tài)C，系統(tǒng)將會進入狀態(tài)A。狀態(tài)B和C，不能同時滿足2個核的要求。

PSCI 1.0之前的版本只支持平臺協(xié)調(diào)模式。

調(diào)用者請求的電源狀態(tài)已經(jīng)是最深休眠狀態(tài)了；

調(diào)用者請求的電源狀態(tài)的喚醒延遲不能比這更長了；

OS協(xié)調(diào)模式

PSCI 1.0引入，這種模式將電源協(xié)調(diào)的權(quán)利交給了OS。這種模式下，只有節(jié)點內(nèi)的最后一個核進入空閑狀態(tài)，OSPM才會為該節(jié)點申請空閑狀態(tài)。

相比平臺協(xié)調(diào)方式，OS協(xié)調(diào)方式則是將怎么選擇最合適的休眠節(jié)點交給了OS，PSCI實現(xiàn)者只需實現(xiàn)，給我什么請求，我就響應(yīng)什么動作即可。示例如下表所示：

如表所示，我們可以看到OS視角和PSCI實現(xiàn)的視角有些不同的地方（紅色標記）。這是因為OS雖然請求了，但是PSCI實現(xiàn)還未響應(yīng)導(dǎo)致的。在上電的時候也會發(fā)生，因為PSCI實現(xiàn)會比OS更早看到CPU核。為了實現(xiàn)OS協(xié)調(diào)方式，必須解決競爭問題。

PSCI實現(xiàn)必須懷疑與自己視角不一樣的電源狀態(tài)請求；

OS必須指明哪個核是最后一個，而且還要指明該核處于哪一級電源中，如，是簇內(nèi)的最后一個核，還是系統(tǒng)內(nèi)最后的一個核。

4.3 CPU熱插拔和輔核啟動

CPU熱插拔的概念不需要再重復(fù)。但是，CPU熱插拔和空閑管理中的powerdown還是有一些差異：

當核被拔出時，監(jiān)控軟件會停止在中斷和線程處理中對該核的所有使用。調(diào)用監(jiān)控軟件認為核不再可用。

想要使用該核，必須發(fā)送命令將核再插入。

喚醒事件不會喚醒被拔出的核。

操作系統(tǒng)通常在主核上完成內(nèi)核的引導(dǎo)過程，然后再啟動輔核。所以，對于支持熱插拔的系統(tǒng)來說，輔核的啟動和hotplug的操作是相同的，可以提供一套接口。

對于運行在單核上的可信OS，移除該核可能不可行，除非把可信OS遷移到其它核上。

PSCI提供具有下列屬性的接口：

監(jiān)控軟件可以請求給一個核上電。監(jiān)控軟件還必須提供一個啟動地址，作為它從安全固件退出時，繼續(xù)執(zhí)行的地方。通過提供一個入口地址，監(jiān)控軟件可以直接在自己的地址空間中干一些特殊的事情。為此，監(jiān)控軟件還必須使用內(nèi)部的per-CPU數(shù)據(jù)結(jié)構(gòu)保存這些值。

監(jiān)控軟件可以請求給一個核掉電。并且還能通知更高異常級別上的軟件。

監(jiān)控軟件還能請求將可信OS遷移到另一個核上。

監(jiān)控軟件，狹義上理解為操作系統(tǒng)的內(nèi)核。

4.4 系統(tǒng)級的shutdown、reset和suspend

PSCI提供了接口，允許OS請求系統(tǒng)system shutdown、system reset和system suspend(suspend-to-RAM)。芯片供應(yīng)商應(yīng)該提供這些函數(shù)的統(tǒng)一實現(xiàn)，它們與監(jiān)控軟件是獨立的。沒有提供suspend-to-disk，這是因為它是系統(tǒng)關(guān)機的一種特殊情況。

這兒，system的意思是從整臺機器的視角看待問題。也就是說，不是單一關(guān)閉某個核或者簇那么簡單。當然，運行在虛擬機中的客戶機OS，如果調(diào)用這些接口不會發(fā)生物理狀態(tài)的變化。

但是，如果沒有hypervisor，或者調(diào)用者是hypervisor，則會導(dǎo)致電源狀態(tài)的物理變化。即使調(diào)用者在物理機器上運行，術(shù)語系統(tǒng)可能也不是指整個物理機器。例如，假設(shè)一個高級服務(wù)器系統(tǒng)由多個單板組成，每個單板具有一個BMC (board management controller)，每個單板包含多個SoC。這樣的系統(tǒng)可以在每個SoC上運行一個OS實例。在本例中，用于關(guān)閉系統(tǒng)的PSCI命令應(yīng)用于單個SoC，而關(guān)閉整個單板需要通過管理接口訪問BMC，而這個管理接口是調(diào)用操作系統(tǒng)或PSCI實現(xiàn)無法訪問的。在本文檔中，術(shù)語系統(tǒng)僅指對操作系統(tǒng)可見的機器視圖。反映到本文檔中，就是指一個SOC。

5 函數(shù)接口描述

功能接口描述。這些API描述不包含底層的SMC或HVC調(diào)用。但是，這些函數(shù)卻都遵守SMCCC調(diào)用規(guī)約。如果實現(xiàn)了EL2卻沒有實現(xiàn)EL3，則hypervisor使用HVC為運行在EL1的Guest OS提供調(diào)用支持。調(diào)用格式都是一樣的。PSCI函數(shù)只能由非安全空間發(fā)起調(diào)用（EL1或EL2）。

5.1 PSCI_VERSION

功能描述

返回PSCI實現(xiàn)的版本號。

參數(shù)

uint32 Function ID: 0x8400 0000

返回值

uint32：

位[31:16]-主版本號；

位[15:0]-次版本號；

注意

對于沒有實現(xiàn)的PSCI函數(shù)，返回NOT_SUPPORTED。

5.2 CPU_SUSPEND

功能描述

掛起CPU核或它之上的更高拓撲結(jié)構(gòu)中的節(jié)點。用于空閑狀態(tài)管理，期望CPU核喚醒時從之前的執(zhí)行位置繼續(xù)執(zhí)行。

參數(shù)

對于powerdown請求，調(diào)用者必須保存復(fù)位重新運行時所需要的狀態(tài)。也就是說保存的上下文必須是調(diào)用者在發(fā)生powerdown調(diào)用之前power_state參數(shù)所指示的電源級別（power_level字段）下所有可見的狀態(tài)。（就是調(diào)用者自己保存自己的狀態(tài)，被調(diào)用者不管）

對于掉電請求，調(diào)用者無需執(zhí)行Cache或一致性操作。PSCI實現(xiàn)者完成（PSCI實現(xiàn)側(cè)負責(zé)內(nèi)存一致性）。

調(diào)用者不能假設(shè)powerdown請求使用指定的entry point地址返回。因為，powerdown可能不能完成，比如因為中斷掛起。也有可能因為與其它核的協(xié)調(diào)，真正進入的是淺睡眠模式（相比請求的休眠模式）。因此，PSCI實現(xiàn)可能將請求的powerdown狀態(tài)降為standby狀態(tài)。如果降為standby狀態(tài)，PSCI實現(xiàn)返回到PSCI調(diào)用之后的指令，而不是指定的entry_point入口地址。此時，返回碼也是成功的。如果發(fā)生比較早的wakeup事件，實現(xiàn)也是返回下一條指令，返回碼也是成功的，也有可能成功的在指定的entry point地址處返回。

正確的喚醒事件必須能夠保證恢復(fù)到之前的狀態(tài)。

CPU_SUSPEND調(diào)用傳遞的入口地址必須是調(diào)用者視角下的物理地址。

上下文標識符只對調(diào)用者有意義。PSCI實現(xiàn)者保存，喚醒時在返回的異常級別下，再傳遞給CPU核，通過該值，恢復(fù)掉電前的上下文。

INVALID_PARAMETERS：如果發(fā)生下面的情況，就會返回該錯誤。

INVALID_ADDRESS

如果傳遞的入口地址，PSCI實現(xiàn)者認為是非法的，就返回該值。

PSCI 1.0之前使用INVALID_PARAMETERS代替該值。

在OS協(xié)調(diào)模式下，如果發(fā)生以下兩種情況，就會返回DENIED：

在OS協(xié)調(diào)模式下，如果系統(tǒng)的狀態(tài)和請求狀態(tài)不一致，會返回INVALID_PARAMETERS，不同之處在于：

為高于核電源級別的拓撲節(jié)點請求低功耗電源狀態(tài)

該節(jié)點中至少一個子節(jié)點與請求的電源狀態(tài)不兼容（比如，一個核發(fā)起請求，將系統(tǒng)級節(jié)點置于powerdown狀態(tài)，但是，該系統(tǒng)節(jié)點中的另一個核處于retention狀態(tài)時，就會返回參數(shù)錯誤。）

提供的power_state參數(shù)不正確。預(yù)期是與平臺固件表（如ACPI或FDT一致）

在OS協(xié)調(diào)模式下，發(fā)生以下兩種條件時，也會返回參數(shù)錯誤：

在DENIED情況中，不一致的核必須運行中。錯誤會出現(xiàn)在調(diào)用者和實現(xiàn)者兩側(cè)。

在INVALID_PARAMETERS情況中，不一致的節(jié)點必須處于低功耗狀態(tài)，不一致只能通過調(diào)用者（OS）的錯誤產(chǎn)生。

為高于核電源級別的拓撲節(jié)點請求低功耗電源狀態(tài)

所有與請求不一致的核必須處于運行中，而不是低功耗狀態(tài)

原始格式

PSCI 1.0之前的版本支持的形式。當使用這種格式時，PSCI_FEATURES使用CPU_SUSPEND功能ID返回的標志字段的bit[1]位被設(shè)置為0。

各比特位的意義：

位域	描述
31:26	保留，必須是0
25:24	PowerLevel
23:17	保留，必須是0
16	StateType
15:0	StateID

擴展StateID：

對于一個硬件平臺，支持每個核、簇或整個系統(tǒng)固定組合狀態(tài)。這些狀態(tài)產(chǎn)生了一組合法的power_state值。這些狀態(tài)應(yīng)該通過固件表（如ACPI或FDT）表示給OSPM。為此，PSCI 1.0引入了一個新的擴展StateID格式。這種格式對于PSCI的實現(xiàn)者來說更為靈活，方便開發(fā)者實現(xiàn)PSCI，可以通過ACPI或FDT電源狀態(tài)的描述進行改進。這樣的情況下，原先的格式有些字段就多余了。

使用這種格式的時候，PSCI_FEATURES函數(shù)的返回標志中的bit[1]會被設(shè)為1（傳遞CPU_SUSPEND功能ID）。

注意：一種實現(xiàn)中不可能混用這兩種格式。

下表是power_state參數(shù)的位域（擴展StateID格式）。

位域	描述
31	保留，必須是0
30	StateType
29:28	保留，必須是0
27:0	StateID

推薦的編碼格式：參考前面。

StateID示例編碼

0，表示standby或retention狀態(tài)；

1，表示powerdown狀態(tài)。另外，還說明entry_point_address和context_id的值合法；

Level 0: 核

Level 1: 簇

Level 2: 系統(tǒng)

PowerLevel，定義的電源域級別，也就是表示是核，簇還是系統(tǒng)層電源請求。

PSCI 1.0之前的版本稱為AffinityLevel。

但是電源域級別的命名，卻是實現(xiàn)者定義的。一般情況下，按照如下方式命名：

StateType：狀態(tài)類型

StateID：狀態(tài)ID

對請求的組合電源狀態(tài)進行標識。一般是實現(xiàn)者定義的。在OS協(xié)調(diào)模式下，StateID必須能夠表示哪個核是最后一個進入idle狀態(tài)的。

這些信息必須體現(xiàn)在FDT或ACPI固件表中，以便在請求電源狀態(tài)時，將這些信息添加到StateID字段中。推薦編碼格式可以參考第6.5小節(jié)。

位域	描述
15:12	核是電源等級中的最后一個 ? 0: Core Level ? 1: Cluster Level ? 2: System Level
11:8	系統(tǒng)級局部電源狀態(tài): ? 0: Run ? 2: Retention ? 3: Powerdown
7:4	簇級局部電源狀態(tài): ? 0: Run ? 2: Retention ? 3: Powerdown
3:0	核級局部電源狀態(tài): ? 0: Run ? 1: standby ? 2: Retention ? 3: Powerdown

0x8400 0001-SMC32版本

0xC400 0001-SMC64版本

uint32 Function ID:

uint32 power_state

從PSCI 1.0開始，支持兩種格式。

entry_point_address

喚醒時，程序繼續(xù)執(zhí)行的起始地址?？梢允荘A（物理地址）或IPA（中間物理地址）。

context_id

該參數(shù)只對調(diào)用者有用。PSCI實現(xiàn)者只需保留一下該參數(shù)的備份即可。從掉電狀態(tài)喚醒時，PSCI將該值寫入到R0、W0或X0通用寄存器中，進入異常的程序會通過該寄存器將保存的上下文內(nèi)容恢復(fù)。

調(diào)用者的責(zé)任

在發(fā)起CPU_SUSPEND調(diào)用之前，非安全空間必須遵守以下規(guī)則：

調(diào)用者必須處理可能的錯誤碼：

PSCI實現(xiàn)者的責(zé)任：狀態(tài)協(xié)調(diào)

在平臺協(xié)調(diào)者模式中，調(diào)用者通過power_state參數(shù)傳遞的指定進入的電源狀態(tài)，在語義上不是強制的。相反，它代表的是調(diào)用者容忍的最深的電源狀態(tài)。此種情況下，是通過PSCI實現(xiàn)真正進入的電源狀態(tài)。為此，如果一個核沒有調(diào)用CPU_ON而上電，或者調(diào)用了CPU_OFF而關(guān)閉的情況下，假定該核進入了最深的電源狀態(tài)。

而在OS協(xié)調(diào)模式中，調(diào)用者顯式請求某個特定的電源狀態(tài)，而不是讓PSCI實現(xiàn)決定。實現(xiàn)必須遵循請求，除非與實現(xiàn)當前的狀態(tài)不一致。

PSCI實現(xiàn)者的責(zé)任：與可信OS或PF進行交互

PSCI實現(xiàn)必須能夠與可信OS或SP進行通信。交互方法請參考ARMv8-A的Firmware Framework。

因為某些原因，可信OS或SP可能不兼容某種特殊的狀態(tài)。這種情況下，ARM建議：可信OS或SP使用自定義的機制與非安全空間通信，保證它的限制可以被非安全空間的代碼考慮。

PSCI實現(xiàn)者的責(zé)任：Cache和內(nèi)存一致性管理

Powerdown狀態(tài)要求清除Cache。PSCI實現(xiàn)者必須在掉電一個節(jié)點之前，為該節(jié)點中所有的Cache和正在最后關(guān)閉的那個核執(zhí)行清除操作。另外，PSCI實現(xiàn)還需要在啟動階段執(zhí)行對Cache的失效操作，除非這是硬件能夠自動完成的。在相關(guān)處理器和互連IP的技術(shù)參考手冊中可以看到，上電或掉電應(yīng)該遵守的順序。

PSCI實現(xiàn)者的責(zé)任：返回狀態(tài)

當從standby狀態(tài)返回時，對于調(diào)用者來說，CPU核的狀態(tài)應(yīng)該沒有變化，除了定時器和由于喚醒中斷造成的CPU interface的變化之外。對于核來說，standby狀態(tài)和使用WFI指令沒有什么不同。唯一的不同就是，調(diào)用SMC指令造成的寄存器變化。R0或W0返回的值是錯誤碼。對于standby狀態(tài)，成功時返回SUCCESS。對于powerdown狀態(tài)，如果成功不會返回，因為喚醒時，從傳遞的入口地址處開始執(zhí)行。如果不成功，返回錯誤碼，表明錯誤原因。

返回值

int32：

SUCCESS;

INVALID_PARAMETERS;

INVALID_ADDRESS;

DENIED;

注意

對于沒有實現(xiàn)的PSCI函數(shù)，返回NOT_SUPPORTED。

5.3 CPU_OFF

功能描述

關(guān)閉核。用于hotplug。只能使用CPU_ON調(diào)用重新開啟一個核。

參數(shù)

0x8400 0002

uint32 Function ID:

返回值

int32：成功不會返回；否則返回DENIED。

5.4 CPU_ON

功能描述

啟動一個核。有兩種情況：（1）啟動階段時調(diào)用；（2）該核之前被CPU_OFF關(guān)閉。

參數(shù)

[24:31]: 必須是0

[16:23]: 匹配MPIDR.Aff2位域

[8:15]: 匹配MPIDR.Aff1位域

[0:7]: 匹配MPIDR.Aff0位域

[40:63]: 必須是0

[32:39]: 匹配MPIDR.Aff3位域

[24:31]: 必須是0

[16:23]: 匹配MPIDR.Aff2位域

[8:15]: 匹配MPIDR.Aff1位域

[0:7]: 匹配MPIDR.Aff0位域

0x8400 0003-SMC32版本

0xC400 0003-SMC64版本

uint32 Function ID: 功能ID

uint32/uint64 target_cpu：目標核

MPIDR寄存器的備份。如果是AArch32：

如果是AArch64：

uint32/uint64 entry_point_address：入口地址

當核返回到非安全異常級時必須執(zhí)行的地址。SMC64版本時，是64位的物理地址或中間物理地址；SMC32版本時，是32位的物理地址或中間物理地址；

uint32/uint64 context_id：上下文地址

當核返回到非安全異常級時：SMC64版本時，該值必須保存在X0寄存器；SMC32版本時，該值必須保存在R0寄存器。需要把該地址的上下文內(nèi)容恢復(fù)（堆棧、執(zhí)行狀態(tài)、中斷狀態(tài)等）。

返回值

int32：

SUCCESS，成功則返回該值；

INVALID_PARAMETERS，描述了一個無效的MPIDR；

INVALID_ADDRESS，ATF認為傳遞進來的入口地址非法；

ALREADY_ON，ATF認為該核已經(jīng)啟動；

ON_PENDING，已經(jīng)發(fā)起了CPU_ON請求，ATF還未處理；

INTERNAL_FAILURE，因為物理原因，不能啟動CPU核。

5.5 AFFINITY_INFO

功能描述

請求某個親和力等級上的信息。

參數(shù)

0：target_affinity中的所有位域都是有效的。在不支持硬件線程化的處理器系統(tǒng)中，target_affinity將會表示單個核。

1：表示target_affinity中，忽略Aff0位域。target_affinity表示親和力等級為1的處理單元。

2：表示target_affinity中，忽略Aff0和Aff1位域。target_affinity表示親和力等級為2的處理單元。

3：表示target_affinity中，忽略Aff0、Aff1和Aff2位域。target_affinity表示親和力等級為3的處理單元。

0x8400 0004-SMC32版本

0xC400 0004-SMC64版本

uint32 Function ID:

target_affinity

同CPU_ON的target_cpu參數(shù)格式一樣。（SMC32或SMC64）

lowest_affinity_level

表示target_affinity參數(shù)中有效的最低親和力級別。該參數(shù)允許AFFINITY_INFO調(diào)用者請求大于0的親和力等級的信息。

可能的值：

從PSCI 1.0版本開始，AFFINITY_INFO不再需要支持高于0的親和級別。

返回值

int32：

2 ON_PENDING，親和力對象正在轉(zhuǎn)換為ON狀態(tài)的過程中；

1 OFF，親和力對象中，所有核都關(guān)閉；

0 ON，親和力對象中，至少有一個核開啟；

INVALID_PARAMETERS（PSCI 1.0以上，請求親和力值大于0的請求會返回該值）；

DISABLED，由于物理原因禁止。

5.6 MIGRATE

功能描述

（可選的）請求將可信OS遷移到另一個核上。

參數(shù)

0x8400 0005-SMC32版本

0xC400 0005-SMC64版本

uint32 Function ID:

target_cpu

同CPU_ON調(diào)用的target_cpu參數(shù)一樣。

返回值

int32：

SUCCESS，成功則返回該值；

NOT_SUPPORTED，不支持該功能，或不需要遷移；

INVALID_PARAMETERS，描述了一個無效的MPIDR；

DENIED，可信OS啟動，但是不可遷移；

INTERNAL_FAILURE，因為物理原因，不能遷移；

NOT_PRESENT，可信OS不在請求的核上。

5.7 MIGRATE_INFO_TYPE

功能描述

（可選的）請求可信OS支持多核的情況。

參數(shù)

0x8400 0006

uint32 Function ID:

返回值

int32：

0 支持單核遷移的可信OS?？尚臤S只能運行在一個核上。可信OS支持遷移功能，可以被遷移到任意一個核上。如果嘗試對運行可信OS的核調(diào)用CPU_OFF，請求會被拒絕（DENIED）。

1 不支持單核遷移的可信OS。可信OS只能運行在一個核上。可信OS不支持遷移功能。調(diào)用MIGRATE會被拒絕。

2 可信OS既不存在、也不需要遷移。這類系統(tǒng)不要求調(diào)用者使用MIGRATE功能。如果硬要調(diào)用，返回NOT_SUPPORTED。

NOT_SUPPORTED 調(diào)用操作系統(tǒng)可以認為等價于返回值為2的情況。

5.8 MIGRATE_INFO_UP_CPU

功能描述

（可選的）返回單核可信OS所在的核。

參數(shù)

0x8400 0007-SMC32版本

0xC400 0007-SMC64版本

uint32 Function ID:

返回值

可能是32位或64位：

UNDEFINED：如果 MIGRATE_INFO_TYPE調(diào)用返回2或NOT_SUPPORTED；

基于MPIDR的值：格式與CPU_ON調(diào)用中的target_cpu參數(shù)一樣。

5.9 SYSTEM_OFF

功能描述

關(guān)閉系統(tǒng)。

SYSTEM_OFF提供了一個系統(tǒng)關(guān)閉的接口。在調(diào)用該接口之前，調(diào)用者必須將所有的核置于已知狀態(tài)。調(diào)用也只能是由非安全空間發(fā)起。一旦發(fā)起該調(diào)用，PSCI實現(xiàn)將會完全關(guān)閉最高等級的電源（也就是系統(tǒng)電源）。

啟動必須是冷啟動。

參數(shù)

0x8400 0008

uint32 Function ID:

返回值

不需要返回。

5.10 SYSTEM_RESET

功能描述

提供系統(tǒng)冷復(fù)位的方法。

參數(shù)

0x8400 0009

uint32 Function ID:

返回值

不需要返回。

5.11 SYSTEM_RESET2

功能描述

（可選）對SYSTEM_RESET的擴展，PSCI 1.1引入。提供：

架構(gòu)相關(guān)的reset方法

供應(yīng)商提供的reset方法

參數(shù)

Bit[31]，保留的話就必須為0.

Bits[30:0]

設(shè)為1，則使用供應(yīng)商提供的reset方法；

設(shè)為0，則為架構(gòu)提供的reset方法；

0x0 SYSTEM_WARM_RESET.

其它值保留.

對于供應(yīng)商提供的reset方法，這些位的意義由供應(yīng)商定義。

對于架構(gòu)提供的reset方法，定義如下：

0x8400 0012-SMC32版本

0xC400 0012-SMC64版本

uint32 Function ID:

reset_type

32位值，被分為兩部分：

cookie

32位或64位值。用來傳遞額外的reset信息。

返回值

int32：

SUCCESS，成功不返回

NOT_SUPPORTED；

INVALID_PARAMETERS；

5.12 MEM_PROTECT

功能描述

（可選）通過在將內(nèi)存移交給操作系統(tǒng)加載程序之前，重寫這段內(nèi)存，來提供針對冷重啟攻擊的保護。PSCI 1.1引入。

參數(shù)

0x8400 0013

uint32 Function ID:

enable

32位值，非0值表示內(nèi)存保護被啟動。0值表示禁止保護功能。

返回值

int32：

成功，則返回之前的使能狀態(tài)：0，表示之前是被禁止的；1，表示之前是使能的。

失敗，則返回NOT_SUPPORTED。

5.13 MEM_PROTECT_CHECK_RANGE

功能描述

（可選）可以檢查某段內(nèi)存是否被MEM_PROTECT保護。PSCI 1.1引入。

參數(shù)

0x8400 0014-SMC32版本

0xC400 0014-SMC64版本

uint32 Function ID:

uint32/64 base

要檢查的內(nèi)存的基地址；

uint32/64 length

要檢查的內(nèi)存的長度；

返回值

int32：

SUCCESS

DENIED

NOT_SUPPORTED

5.14 PSCI_FEATURES

功能描述

查詢SMCCC_VERSION或者某個PSCI功能是否被實現(xiàn)。PSCI 1.0引入。

參數(shù)

0x8400 000A

uint32 Function ID:

psci_func_id

功能ID：PSCI或SMCCC_VERSION

返回值

如果功能實現(xiàn)，則意義如下：

psci_func_id	標志位	描述
CPU_SUSPEND功能ID	[31:2]	保留，等于0
	[1]	0，power_state使用原始格式(PSCI 2.0) 1，power_state新的擴展StateID格式
	[0]	0，不支持OS協(xié)調(diào)方式 1，支持OS協(xié)調(diào)方式
其它功能ID	[31:0]	保留都是0

5.15 CPU_FREEZE

功能描述

（可選）將核置于供應(yīng)商自定義的低功耗狀態(tài)中。與CPU_OFF不同，中斷仍然可以傳遞給該核。但是，該核一直會處于低功耗狀態(tài)中，直到CPU_ON調(diào)用將其啟動。PSCI 1.0引入。

參數(shù)

0x8400 000B

uint32 Function ID:

返回值

int32：

成功，不返回。

失敗，則返回NOT_SUPPORTED或DENIED。

5.16 CPU_DEFAULT_SUSPEND

功能描述

（可選）將核置于供應(yīng)商自定義的低功耗狀態(tài)中。與CPU_SUSPEND不同的是，不需要指定power_state參數(shù)。PSCI 1.0引入。

參數(shù)

0x8400 000C-SMC32版本

0xC400 000C-SMC64版本

uint32 Function ID:

entry_point_address

參考CPU_SUSPEND；

context_id

參考CPU_SUSPEND；

返回值

int32：

SUCCESS

INVALID_ADDRESS

5.17 NODE_HW_STATE

功能描述

（可選）返回系統(tǒng)的電源域拓撲結(jié)構(gòu)中一個節(jié)點的硬件狀態(tài)。PSCI 1.0引入。

參數(shù)

0x8400 000D-SMC32版本

0xC400 000D-SMC64版本

uint32 Function ID:

target_cpu

參考CPU_ON；

power_level

表示想要請求的節(jié)點，在電源域拓撲結(jié)構(gòu)的層級。這是供應(yīng)商自定義的，但是0保留給CPU核。

返回值

int32：

2 HW_STANDBY：返回2，表示處于standby或retention電源狀態(tài)；

1 HW_OFF：返回1，表示處于powerdown狀態(tài)；

0 HW_ON：返回0，表示處于run狀態(tài)；

NOT_SUPPORTED

INVALID_PARAMETERS

5.18 SYSTEM_SUSPEND

功能描述

語義等價于CPU_SUSPEND，將系統(tǒng)置于最低功耗狀態(tài)。該調(diào)用是實現(xiàn)system suspend-to-RAM的基礎(chǔ)（ACPI規(guī)范中描述的S2和S3狀態(tài)）。值得注意的是，系統(tǒng)進入S2或S3狀態(tài)，需要幾個前提條件。系統(tǒng)中所有設(shè)備必須與進入該系統(tǒng)掛起狀態(tài)兼容，可能需要在調(diào)用之前，優(yōu)雅地處理各個外設(shè)。這些前提條件不在本文的討論范圍內(nèi)。SYSTEM_SUSPEND僅限于提供進入S2或S3狀態(tài)的機制，所有必要的條件都由調(diào)用OS滿足。盡管ACPI將suspend-to-RAM功能分為S2或S3兩種狀態(tài)，但是PSCI只提供了一個API。

同SYSTEM_SHUTDOWN和SYSTEM_RESET一樣，該函數(shù)適用于調(diào)用OS的機器視角。

為了使用該函數(shù)調(diào)用，調(diào)用者必須使用CPU_OFF關(guān)閉所有的核，但保留一個核。剩下的這個核調(diào)用SYSTEM_SUSPEND，傳遞entry_point_address和context_id參數(shù)（喚醒時用），進入掛起狀態(tài)。調(diào)用者（OS）可以在調(diào)用SYSTEM_SUSPEND之前，使用AFFINITY_INFO函數(shù)保證所有其它核都已關(guān)閉。

參數(shù)

0x8400 000E-SMC32版本

0xC400 000E-SMC64版本

uint32 Function ID:

entry_point_address：參考CPU_SUSPEND

context_id：參考CPU_SUSPEND

返回值

返回32位值。

NOT_SUPPORTED

INVALID_ADDRESS

ALREADY_ON

成功不會返回；

失敗則返回：

5.19 PSCI_SET_SUSPEND_MODE

功能描述

（可選）設(shè)置電源狀態(tài)協(xié)調(diào)方式。PSCI 1.0引入。

參數(shù)

0: 平臺協(xié)調(diào)方式

1: OS協(xié)調(diào)方式

0x8400 000F

uint32 Function ID:

mode

返回值

int32

SUCCESS

NOT_SUPPORTED

INVALID_PARAMETERS

DENIED

5.20 PSCI_STAT_RESIDENCY

功能描述

（可選）返回冷啟動之后，在某種狀態(tài)下的度過時間。PSCI 1.0引入。

參數(shù)

0x8400 0010-SMC32版本

0xC400 0010-SMC64版本

uint32 Function ID:

target_cpu

格式與CPU_ON調(diào)用相同；

power_state

指定的電源狀態(tài)。

返回值

可能是32位或64位。返回處于指定電源狀態(tài)的時間。

5.21 PSCI_STAT_COUNT

功能描述

（可選）返回冷啟動之后，進入某種狀態(tài)下的次數(shù)。PSCI 1.0引入。

參數(shù)

0x8400 0010-SMC32版本

0xC400 0010-SMC64版本

uint32 Function ID:

target_cpu

格式與CPU_ON調(diào)用相同；

power_state

指定的電源狀態(tài)。

返回值

可能是32位或64位。進入某種狀態(tài)下的次數(shù)。

5.22 錯誤碼

定義	值
SUCCESS	0
NOT_SUPPORTED	-1
INVALID_PARAMETERS	-2
DENIED	-3
ALREADY_ON	-4
ON_PENDING	-5
INTERNAL_FAILURE	-6
NOT_PRESENT	-7
DISABLED	-8
INVALID_ADDRESS	-9

6 其它實現(xiàn)細節(jié)

6.1 PSCI調(diào)用流程

6.1.1 CPU_SUSPEND、CPU_DEFAULT_SUSPEND和SYSTEM_SUSPEND調(diào)用流程

6.1.2 CPU_OFF調(diào)用流程

6.1.3 CPU_ON調(diào)用流程

審核編輯：郭婷