Post on 26-May-2015
description
1
Power Management Across OSs
charles.garcia-tobin@arm.com
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
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
ARMv7/v8 Privilege/Exception Levels
Apps Apps
Apps Apps
Guest OS
Apps Apps
Apps Apps
Guest OS
Hypervisor
Secure Apps Secure
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 Apps Secure
Apps
Secure OS
Secure Monitor
PL0
PL1
PL2
Non-Secure
ARMv7 ARMv8
5
ARMv7/v8 Privilege/Exception Levels
Apps Apps
Apps Apps
Guest OS
Apps Apps
Apps Apps
Guest OS
Hypervisor
Secure Apps Secure
Apps
Trusted OS
Secure Monitor
PL0
PL1
PL2
Non-Secure
ARMv7
Rich OSs Linux, Windows
...
Hyp vendors OKLabs, VMWare
...
TrustedOS Vendors Semicos, ...
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
Power controller
optional
bigLITTLE migration
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
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
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
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
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
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
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
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
1 3
1
2
3
2
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
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
17
Migration with Power Up/Down
18
Migration State Transfer
1 2
1 2
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
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
Status Standard calling conventions
Secure monitor SMC Hypervisor HVC
ARM will be providing sample secure code for power interface
Questions ...