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...
3
Linux is not Alone on the Device
 Secure code will be present, provided by Semico or trusted
OS vendor for a variety re...
4
ARMv7/v8 Privilege/Exception Levels
Apps
Apps
Apps
Apps
Guest OS
Apps
Apps
Apps
Apps
Guest OS
Hypervisor
Secure
AppsSecu...
5
ARMv7/v8 Privilege/Exception Levels
Apps
Apps
Apps
Apps
Guest OS
Apps
Apps
Apps
Apps
Guest OS
Hypervisor
Secure
AppsSecu...
6
So Need Collaboration
 Need OSs at different privilege
layers to collaborate on power
 OSs need to know when to
save/r...
7
Cold Boot vs Warm Boot
Linux Kernel
Secure ROM
Goto TrustedOS
Warm boot vector
Secure ROM
Init
check boot reason
Secure ...
8
Cold Boot vs Warm Boot
Linux Kernel
Secure ROM
Goto TrustedOS
Warm boot vector
Secure ROM
Init
check boot reason
Secure ...
9
Context
 Idle management use of shutdown states requires context saving and restoring
 big.LITTLE migration models req...
10
Proposal
 System APIs are required by
 Idle states
 Hot plug
 Secondary boot
 CPU Migration (Switching)
 Can be c...
11
Conduit to next layer of privilege
 To talk across OSs you need instructions that can get you up
to next level of priv...
12
Powering Down a CPU for Idle
 We want to capture the following semantics:
 What is being powered down:
 You can powe...
13
Powering Down a CPU for Idle
 What is being powered down?
 We can use an affinity level
 Affinity level 0 -> current...
14
Power Down – Resume Address & Context ID
 Resume address
 Address at which
calling OS expects
to be restarted
 Conte...
15
Power Down
 IdlePowerDown
 Parameters
 Affinity level: CPU or cluster (or indeed cluster of clusters ...)
 Resume a...
16
Power Up/Down – HotPlug
 Hot Plug - CPURemove
 Parameters
 Affinity level: CPU or cluster (or indeed cluster of clus...
17
Migration with Power Up/Down
18
Migration State Transfer
12
1 2
19
Power Up for CPU Switching
 SwitchIn
 Secure World knows that the intent is a switch
 Parameters
 CPUID of inbound ...
20
Power Down for Migration
 SwitchOut
 Parameters
 Affinity Level to power down
 Resume vector and contextID
 Must m...
21
Status
 Standard calling conventions
 Secure monitor SMC
 Hypervisor HVC
 ARM will be providing sample secure code ...
Upcoming SlideShare
Loading in...5
×

Q2.12: Power Management Across OSs

368
-1

Published on

Resource: Q2.12
Name: Power Management Across OSs
Date: 01-06-2012
Speaker: Charles Garcia-Tobin

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
368
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Q2.12: Power Management Across OSs

  1. 1. 1 Power Management Across OSs charles.garcia-tobin@arm.com
  2. 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. 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. 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
  5. 5. 5 ARMv7/v8 Privilege/Exception Levels Apps Apps Apps Apps Guest OS Apps Apps Apps Apps Guest OS Hypervisor Secure AppsSecure Apps Trusted OS Secure Monitor PL0 PL1 PL2 Non-Secure ARMv7 Rich OSs Linux, Windows ... Hyp vendors OKLabs, VMWare ... TrustedOS Vendors Semicos, ...
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. 17 Migration with Power Up/Down
  18. 18. 18 Migration State Transfer 12 1 2
  19. 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. 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. 21 Status  Standard calling conventions  Secure monitor SMC  Hypervisor HVC  ARM will be providing sample secure code for power interface  Questions ...
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×