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 ...