PowerManagement

KVM Power Management Support.

S4 support (Hibernate on Windows. echo disk > /sys/power/state on Linux)

S4 does not require any particular support from KVM or BIOS. If BIOS advertise that it has support for S4 by having \_S4 defined in DSDT aml then Windows enables Hibernate option in reboot menu. On hibernate OS dumps memory state to a disk and powers off a computer by writing to appropriate PM register (at this point QEMU process will terminate). On a next boot BIOS goes through the normal POST and transfer control to an OS loader the OS checks if hibernate file exists and resumes from hibernate if yes. All devices are reinitialized by the OS.

S3 support (Sleep/Stand By on Windows, echo mem > /sys/power/state on Linux)

S3 requires BIOS support. During S3 state memory is powered on and its content is preserved so OS does not save it to a disk. OS should save state of each device though, as they will be powered down and will lose their configuration. BIOS has to know that resume from S3 is in progress and take special steps to ensure that memory areas available to an OS are stay intact. BIOS can use first page of the memory (since OSes assumes that the page is used by BIOS) and any memory protected by E820 map (real BIOSes are more lucky as they can use CPU cache as a memory). On POST BIOS should not initialize any devices used by an OS and no boot loading process takes place, BIOS just jumps to a resume vector that OS writes to a location known by BIOS before transferring control to a BIOS. Control is transfered by writing special value to PM register (the value to write to enter specific Sx state is specified by \_Sx method in DSDT aml code). Currently when QEMU gets a request to move to S3 state it save special value in cmos, so BIOS can distinguish between regular boot and S3 resume, and calls qemu_system_reset_request(). Reset starts to execute BIOS and resume happens immediately.

Windows issues

Windows requires all active drivers to support power management state it wants to move into. If even a single driver does not advertise that the state is supported Windows refuses to enter the state. SVGA driver does not support S3 state, so any Windows variant that uses it for QEMU emulated vga card will refuse to enter S3 state. WindowsXP/2003 will present user with an option, but attempt to do "stand by" will fail. Windows Vist/2008 will not even provide a sleep option. There is only two variants of Windows that does not use SVGA driver in QEMU: WindowsXP/2003 32 bit. They use cirrus driver. Cirrus driver also does not support S3 state, but it can be tricked to do S3 anyway. The trick is to tell Windows there is no need to powerdown cirrus card when entering S3 state (this is done by specifying Sx->Dx mapping in DSDT aml). The problem is that QEMU resets all devices (including cirrus vga) during S3 and windows does not know how to restore it, so after resume the cirrus state is not what Window expects it to be. The result is that after resume Windows display is corrupted.

When I worked on S3 there was a bug in QEMU. Cirrus was not reset on system reset, so resume worked as expected, but since then the bug was fixed (commit 4abc796d41ee01a698032e74ac17c1cdc5d290c3 "Add cirrus reset handler"). The fix is in all relevant (for us) trees: Avi's upstream and RHEV.

Windows Tools

To query power management status use powercfg.
Offline tests of power management:
1. http://www.passmark.com/products/sleeper.htm - good for any system.
2. WDK tool - works on Vista/2008: {WDK}\\tools\acpi\pwrtest, provides in the log file some more information about suspend/resume timing.