This document proposes a standardized interface for collaborating on power management across operating systems on ARM devices. It suggests defining a set of APIs to handle powering down and up CPUs for idle states, hot plug, secondary boot, and CPU migration. These APIs would take parameters like the affinity level, resume address, and context ID to enable saving and restoring state across OS layers. Implementing this interface with calls like IdlePowerDown, CPUAdd, CPURemove, CPUSwitchIn, and CPUSwitchOut could facilitate collaboration between Linux, hypervisors, and trusted operating systems on power management.
2. 2
Introduction
Firmware/ACPI is not the most popular topic in Linux:
“Modern PCs are horrible. ACPI is a complete design disaster in every
way. But we're kind of stuck with it. If any Intel people are listening to
this and you had anything to do with ACPI, shoot yourself now, before
you reproduce”
“The fact that ACPI was designed by a group of monkeys high on LSD,
and is some of the worst designs in the industry obviously makes
running it at any point pretty damn ugly. “
“EFI is this other Intel brain-damage (the first one being ACPI). “
3. 3
Linux is not Alone on the Device
Secure code will be present, provided by Semico or trusted
OS vendor for a variety reasons:
Secure boot
Crypto services
Secure key storage
....
Global platform is a leading security standards body in mobile
space
Most companies in this room are members
Hypervisor can also be present
There is actually a work item in Linaro to cover Trustzone
TrustZone kernel driver
4. 4
ARMv7/v8 Privilege/Exception Levels
Apps
Apps
Apps
Apps
Guest OS
Apps
Apps
Apps
Apps
Guest OS
Hypervisor
Secure
AppsSecure
Apps
Secure OS
Secure Monitor
EL0
EL1
EL2
EL3
Non-Secure Secure
32-bit &
64-bit
Apps
Guest OS
64-bit
Hypervisor
Monitor
Apps
Apps
Apps
Apps
Guest OS
Apps
Apps
Apps
Apps
Guest OS
Hypervisor
Secure
AppsSecure
Apps
Secure OS
Secure Monitor
PL0
PL1
PL2
Non-Secure
ARMv7 ARMv8
6. 6
So Need Collaboration
Need OSs at different privilege
layers to collaborate on power
OSs need to know when to
save/restore their state
OSs need to manage peripherals
they own when entering a power
state
Linux
Hypervisor
Secure world
Hotplug
Secondary boot
Idle
Powercontroller
optional
bigLITTLE migration
7. 7
Cold Boot vs Warm Boot
Linux Kernel
Secure ROM
Goto TrustedOS
Warm boot vector
Secure ROM
Init
check boot reason
Secure Flash
Boot firmware
Install TrustedOS
Uboot
Load linux from
media
Trusted OS
Start RichOS at
Its warm boot vector
Linux Kernel
Secure
Non-Secure
8. 8
Cold Boot vs Warm Boot
Linux Kernel
Secure ROM
Goto TrustedOS
Warm boot vector
Secure ROM
Init
check boot reason
Secure Flash
Boot firmware
Install TrustedOS
Uboot
Load linux from
media
Trusted OS
Start RichOS at
Its warm boot vector
Linux Kernel
Secure
Non-Secure
Linux needs to define warm boot address and inform secure side
9. 9
Context
Idle management use of shutdown states requires context saving and restoring
big.LITTLE migration models require saving context, and restoring on a different
CPU
Every OS layer may need to save context, and every booting CPU needs a
context for every OS layer
10. 10
Proposal
System APIs are required by
Idle states
Hot plug
Secondary boot
CPU Migration (Switching)
Can be captured in a few APIs:
Power down CPU for Idle -> IdlePowerDown
Power up CPU for hot plug -> CPUAdd
Power down a CPU for hot unplug -> CPURemove
Power up the inbound CPU for migration -> CPUSwitchIn
Power down the outbound CPU for migration -> CPUSwitchOut
11. 11
Conduit to next layer of privilege
To talk across OSs you need instructions that can get you up
to next level of privilege
SMC provides such an interface.
SMC can also be trapped at hypervisor level
A virtualised guest can use the same interface
12. 12
Powering Down a CPU for Idle
We want to capture the following semantics:
What is being powered down:
You can power the current CPU down
If last man you can power the current cluster down
How do express a return address? How do express what context to
use when you restart
13. 13
Powering Down a CPU for Idle
What is being powered down?
We can use an affinity level
Affinity level 0 -> current CPU
Affinity Level 1 -> Current cluster
Affinity Level 2 -> Current cluster of clusters / whole system
CPU identification scheme in ARMv7 define three affinity levels
OS managing power is responsible for tracking “last man” and
synchronising entry
14. 14
Power Down – Resume Address & Context ID
Resume address
Address at which
calling OS expects
to be restarted
Context ID
Opaque value
understood by
calling OS which
must be in R0
when OS is
resumed
13
1
2
3
2
15. 15
Power Down
IdlePowerDown
Parameters
Affinity level: CPU or cluster (or indeed cluster of clusters ...)
Resume address and context ID
Return
Invalid parameters
Success
16. 16
Power Up/Down – HotPlug
Hot Plug - CPURemove
Parameters
Affinity level: CPU or cluster (or indeed cluster of clusters ...)
OS has to track last man
Hot Unplug or secondary cold boot - CPUAdd
Parameters
CPUID of core being powered up
Resume address and context ID
Return
Invalid Parameters
Success
19. 19
Power Up for CPU Switching
SwitchIn
Secure World knows that the intent is a switch
Parameters
CPUID of inbound core
Resume vector and contextID
Return
Success
TryAgain
Invalid parameters
20. 20
Power Down for Migration
SwitchOut
Parameters
Affinity Level to power down
Resume vector and contextID
Must match ones used in SwitchIn
Return
Invalid parameters
21. 21
Status
Standard calling conventions
Secure monitor SMC
Hypervisor HVC
ARM will be providing sample secure code for power
interface
Questions ...