ARM Power State Coordination Interface (PSCI)规格草案：协调平台电源状态

需积分: 0 184 浏览量更新于2024-06-27 收藏 1.69MB PDF 举报

DEN0022E-Power-State-Coordination-Interface (PSCI) 是 Arm 公司制定的一份平台设计文档，旨在协调基于 Arm 架构的系统中的电源管理状态。这份工程草案版本是非保密的 Beta 版本，目的是从 Arm 合作伙伴和内部获取反馈，以便根据反馈进行调整。文档涵盖了版权信息、文档许可、引用、术语和缩略语、反馈机制、逐步术语承诺、假设与推荐以及 PSCI 的核心概念。 PSCI 的主要目标是确保在不同安全级别（如 Armv7 的特权级别）下，系统的软件堆栈能够有效地管理电源状态，包括但不限于唤醒、休眠和低功耗模式。它特别关注于处理系统级的电源管理协调，如在虚拟化环境中的应用，以及跨多个安全域（Realms）的权力策略。文档详细描述了以下关键部分： 1. **版权和文档使用**: - 文档受版权保护，Arm 或其关联公司保留所有权利。 - 提供了 Arm 非保密文档许可条款，规定了使用此文档的条件。 2. **文档结构**: - 引用列表提供了相关参考文献。 - 定义了术语和缩写，以便读者理解专业术语。 3. **获取反馈**: - 邀请 Arm 合作伙伴和内部团队提供对文档的反馈，以便进行后续的改进。 4. **PSCI 功能与应用场景**: - PSCI 主要用于处理系统进入和退出不同电源状态的过程，包括管理设备的休眠和唤醒，特别是在虚拟化环境中，它需要确保各个安全域之间的协调。 - 详细的使用案例（如 idle management）被提出，以明确功能需求和预期行为。 5. **安全等级与特权控制**: - PSCI 被设计为在不同的异常级别（Exception levels）上运行，其中 Armv7 的特权级别起着关键作用，确保在最高特权级别下执行电源管理任务。 6. **软件堆栈和硬件接口**: - 描述了在 Arm 基础架构上的软件栈如何与 PSCI 接口交互，以及如何通过称为"conduits"的机制实现电源管理的通信。 7. **安全世界软件与电源管理**: - 着重强调了在安全世界（Secure World）中的软件如何利用 PSCI 来实施严格的电源管理策略，以保证系统安全。 DEN0022E-Power-State-Coordination-Interface 是一个重要的技术文档，它定义了 Arm 平台上的电源管理接口标准，确保在多特权级和安全环境下，系统的高效能和安全性得到优化。通过反馈机制，该文档旨在不断迭代和完善，以适应不断发展的硬件和软件需求。

Power State Coordination Interface

Non-Confidential

Assumptions and recommendations

This document defines an API that can be used to coordinate power control among supervisory

systems concurrently running on a device. As the following sections explain, the API allows a

supervisory system to request cores to be powered up or down, and to request context transfer of

secure context from one core to another, which might be needed when dealing with trusted OSs or SPs.

Throughout the description, the document generally assumes that EL2 and EL3 are both implemented,

but also covers other cases.

3.1 PSCI intended use

PSCI has the following intended uses:

• Provides a generic interface that supervisory software can use to manage power in the following

situations:

• Core idle management.

• Dynamic addition of cores to and removal of cores from the system, often referred to as

hotplug.

• Secondary core boot.

• Moving trusted OS context from one core to another.

• System shutdown and reset.

• Provides an interface that supervisory software can use in conjunction with Firmware Table (FDT

and ACPI) descriptions to support the generalization of power management code.

PSCI does not cover:

• Peripheral idle management. PSCI only applies to idle management of the cores used by the central

scheduler of supervisory software.

• Dynamic Voltage and Frequency Scaling. PSCI does not provide interfaces for the management of

core clock frequencies on a device.

PSCI does not provide power state representations to supervisory software. However, it is designed so

that it can also be used with hardware description technologies such as ACPI or FDT.

3.2 Exception levels, the Armv7 privilege levels, and highest privilege

Armv8 introduces explicit Exception levels that also define the software execution privilege hierarchy

within a Security state. An increase in Exception level, for example from EL0 to EL1, corresponds to an

increase in execution privilege.

In Armv7, the Exception level hierarchy is implicit in the architecture:

• The Virtualization Extensions provide the EL2 functionality. This is present only in Non-secure state.

• The Security Extensions provide the EL3 functionality, including the support for two Security states.

The control features of this functionality are provided by a Monitor mode that is present only in

Secure state.

The Armv7 architecture [1] uses Privilege levels (PLs) to describe the software execution privilege

hierarchy. Because Monitor mode was defined as a peer of the other Secure state privileged processor

Power State Coordination Interface

Non-Confidential

modes, this means the Armv7 privilege levels are asymmetrical between Non-secure state and Secure

state, as follows:

• In Non-secure state, the privilege level hierarchy is:

• PL0, unprivileged. Applies to User mode.

• PL1, OS-level privilege. Applies to System, FIQ, IRQ, Supervisor, Abort, and Undefined

modes.

• PL2, hypervisor privilege. Applies to Hyp mode.

• In Secure state, the privilege level hierarchy is:

• Secure PL0, unprivileged. Applies only to User mode.

• Secure PL1, Trusted OS, and Monitor level privilege. Applies to System, FIQ, IRQ,

Supervisor, Abort, Undefined, and Monitor modes.

In the AArch32 description of execution privilege [5], which applies to both Armv7 and Armv8

implementations, the processor modes map to the Exception levels as follows:

• In Non-secure state, the processor modes implemented at each Exception level are:

• EL0: User mode.

• EL1: System, FIQ, IRQ, Supervisor, Abort, and Undefined modes.

• EL2: Hyp mode.

• In Secure state, the processor modes implemented at each Exception level are:

• Secure EL0: User mode.

• EL3: System, FIQ, IRQ, Supervisor, Abort, Undefined, and Monitor modes.

Note: In an Armv8 implementation, this mapping of the Secure modes applies only when EL3 is using

AArch32. When EL3 is using AArch64, Monitor mode is not implemented, and if Secure EL1 is

using AArch32 then Secure System, FIQ, IRQ, Supervisor, Abort, and Undefined modes are

implemented as part of Secure EL1. For more information see [5].

This document generally uses Exception level terminology. In the document:

• References to EL2, EL1 and EL0 refer to Non-secure exception levels unless otherwise indicated.

Secure EL2, Secure EL1 and Secure EL0 are referred to as S-EL2, S-EL1 and S-EL0. When Arm

Realm Management Extension (RME) [12][13] is implemented, Realm EL2, Realm EL1 and Realm

EL0 are referred to as R-EL2, R-EL1 and R-EL0. In general, the PSCI interface between R-EL1

and R-EL2 follow the same semantics as the interface between NS-EL1 and NS-EL2. For more

details see the Realm Management Monitor Specification [14].

• Highest privilege refers to the first implemented Exception level in the following sequence, which

runs from highest to lowest: EL3, Secure EL2, Secure EL1, Non-secure EL2, Non-secure EL1.

Power State Coordination Interface

Non-Confidential

3.3 Software stacks on Arm-based systems

On a given Arm device there can be several supervisory software kernels or privileged software

components.

Figure 1 Software Layers of an Arm system

Figure 1 Software Layers of an Arm system illustrates these various layers. The Realm Security state

incorporates the Realm and the Realm Management Monitor (RMM) [14]. The Normal (Non-secure)

world has the following privileged components:

Rich OS kernels: Examples include Linux or Windows running in Non-secure EL1. When running

under a hypervisor, the Rich OS kernels can be running as guests or hosts depending on the

hypervisor model.

Hypervisor: This component runs at Non-secure EL2. This component, when present and enabled,

provides virtualization services to guests running Rich OS kernels.

The Secure world has the following privileged components:

Privileged Platform Firmware (PPF): Owned by the silicon vendor and OEM. This firmware layer is

the first thing that runs at boot on an application processor. It provides several services,

including platform initialization, the installation of lower Exception level software components,

and routing of Secure Monitor Calls. PPF can run in EL3, Secure EL2 and Secure EL1 on

Armv8 systems using AArch64 in EL3. Arm strongly recommends using EL3 for PPF. For Armv7

systems, or Armv8 systems using AArch32 at EL3, PPF executes in EL3. The PPF must include

the implementation that acts on power management requests made via the Power State

Coordination Interface. When Arm RME [12][13] is implemented and enabled, the

implementation that acts on power management requests made via the Power State

Coordination Interface should reside in EL3. A reference implementation for privileged platform

FW is provided by the Trusted Firmware-A open-source project [8].

Trusted OS: This provides secure services to the Normal world and provides a runtime environment for

executing secure applications. In AArch32 state Trusted OS software executes in Secure EL3,

and in AArch64 state it primarily executes in Secure EL1.

Power State Coordination Interface

Non-Confidential

Note: While the Arm Architecture Reference Manuals [1, 5] define Secure and Non-secure Security

states, and the Arm processor documentation uses these state names. Arm software documentation

often refers to these states as Secure and Normal world, respectively. This reflects the fact that

software normally executes in Non-secure state.

The PSCI specification focuses on the interface between Security states for power management. It

provides a method for issuing power management requests. To deal with the requests, the PPF must

include a PSCI implementation. A PSCI implementation might require communication between the PPF

and a Trusted OS or SP. Currently, how this communication is handled is specific to individual vendors.

Arm recommends using the Firmware Framework for Arm v8-A [10] to handle this communication.

Although the PSCI specification focuses on power management requests between Security states, the

interface can also be reused easily at the junction between Rich OS kernels and hypervisors, or Realms

and Realm Management Monitor (RMM).

3.4 Conduits

The PSCI interface must support interaction at all levels of execution implemented on the device, where

multiple levels of supervisory software might be executing. For the caller operating in the Normal world,

the interface must forward a message to the PPF. In a system that implements EL2, it must be possible

to trap interface calls made by the EL1 kernel context to the hypervisor (EL2). In a system that

implements Arm RME, it must be possible to trap interface calls made by the Realm executing at R-

EL1, to the RMM executing at R-EL2. The RMM can then decide to forward the call to the Hypervisor

executing at NS-EL2 [14]. If the hypervisor determines that a change of physical power state is

required, it must then be able to use the PSCI interface to inform the PPF.

The conduits available to transfer a message from one Exception level to another depend on the

implemented Exception levels and Security states. For further information on the description of possible

conduits, see [4] and [14].

3.5 Secure world software and power management

Many Trusted OS implementations are not SMP-capable. When running on MP devices, they are tied to

a single core. Secure Monitor Calls destined for the Trusted OS are only expected to come from that

core. The lack of MP support in the OS helps to keep Trusted code simple and small, which in turn aids

certification. Trusted OS services are invoked from the Normal world through Rich OS drivers or

daemons that are provided with the Trusted OS implementations. The threads associated with these

drivers and daemons are normally affinitized to the core used by the Trusted OS.

Arm systems generally include a power controller, or control logic, that can manage core power. This

normally provides interfaces that support several power management functions. Often these include

support for transitioning cores, clusters, or a superset into low-power states. In the low-power state, the

cores are either fully switched off or in quiescent states where they are not executing code. Arm

strongly recommends that the EL3 is responsible for the control of these states. Otherwise,

cleanup of the Root and Secure state, including cache clean, is not possible prior to entering the low-

power state. Other forms of power management, such as dynamic performance management through

voltage and frequency scaling, are not covered by this interface. Arm strongly recommends that all

policy in power and performance management is performed in the Normal world. The Normal

world has greater visibility of the current use and purpose of a given device. Where the Secure world

has performance requirements, Arm recommends that IMPLEMENTATION DEFINED mechanisms are

used to communicate those requirements to the Normal world.

Power State Coordination Interface

Non-Confidential

3.6 Virtualization, Realms, and core power policy

Hypervisors are broadly split into two basic types:

Type 1: Sometimes described as native or bare metal. Type 1 hypervisors execute directly on the

hardware. Any application guest OS sees a virtualized view of this hardware.

Type 2: Sometimes described as hosted. Type 2 hypervisors run within a host OS. The host OS has a

physical view of the hardware it runs on, but guest operating systems see a virtualized view.

This is a very broad categorization. In reality, there are variations on the above. The Armv8 architecture

allows running a type 2 hypervisor at EL1 or EL2. This blurs the differences between type 1 and type 2.

From a power management perspective, and for the purposes of this document, a type 2 hypervisor or

host running at EL2, is analogous to a type 1 hypervisor. However, in general terms these two

abstractions capture the forms of power management required by the hypervisors.

From the point of view of power management and virtualization there are two types of OSPM:

Physical OSPM: This comprises the software components that select the physical power states.

Virtual OSPM: This is an OSPM that is present in a guest OS running a virtual machine, which selects

virtual, rather than physical power states.

With type 2 hypervisors, the physical OSPM resides in the host. Actual power policy is controlled from a

Rich OS typically running at EL1. The physical OSPM is contained in this Rich OS. This layer has a

physical view of the cores. An example of this is shown in Figure 2 on the left-hand side.

Figure 2 Typical Power management models in virtualization

For the power management functions covered in this document, type 2 hypervisor behavior depends on

the caller. If the caller is the host, the hypervisor complies with the power request or allows the call to

pass straight through to the privileged platform firmware. The hypervisor typically only performs any

necessary operations resulting from the call, for example, saving state on a powerdown if needed. From

this point onwards, the hypervisor calls through to the privileged platform firmware using the parameters

supplied by the caller. If no special operations are required, the hypervisor does not even trap calls from

the host, and instead routes them directly to the privileged platform firmware. Guests, on the other

hand, use a virtual OSPM. They can also issue power requests through the PSCI APIs, but the

requests are issued in relation to virtual cores and virtual power states. These requests are trapped by

the hypervisor, which issues them back to the physical OSPM. This component can then determine

whether physical power management is required. For these guests, the power calls effectively terminate

at the hypervisor.

With a type 1 hypervisor, power policy is typically owned entirely by the hypervisor. This is shown on

the right-hand side in Figure 2. The physical OSPM is implemented in the hypervisor. In this case all

剩余91页未读，继续阅读

TrustZone_Hcoco

粉丝: 2w+
资源: 32

ARM Power State Coordination Interface (PSCI)规格草案：协调平台电源状态

Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

make menuconfig 中的 [ ] Support for the ARM Power State Coordination Interface (PSCI) 介绍

E-UTRAN采用了哪些更高效的功率控制和干扰管理技术

cannot get resource leases in API group coordination.k8s.io in the namespace kube-system

distributed coordination of multi-agent networks pdf

cve-2021-1682

cve-2022-41741

CVE-2023-48795

CVE-2022-23943

CVE-2023-0215

最新资源