On Mon, Nov 21, 2011 at 05:26:55PM -0700, Eric Blake wrote: > On 11/09/2011 05:05 AM, Srivatsa S. Bhat wrote: > > (This patch is positioned to go in after the patch that exports the host > > power management capabilities as XML, posted in [4]) > > I'm now reviewing that patch along with this series; if we need another > revision, it may be easiest to merge the three patches into a single > series and title it v6, so that they are together in one thread. > > > > > This patch adds a new API to put a host to a suspended state (either > > Suspend-to-RAM or Suspend-to-Disk) and setup a timed resume to get the > > host back online, from within libvirt. > > This uses the RTC wakeup mechanism to set up a timer alarm before > > suspending the host, so that in-band resume is facilitated by the firing > > of the RTC alarm, which wakes up the host. > > I'm not as familiar with S3/S4 as I would like to be - am I correct that > RTC wakeup works for S3 (where the host is maintaining minimal power and > can thus react to interrupts), but not S4 (where the host has flushed > completely to disk and powers off, but resumes from the state on disk on > next power on)? Or am I misunderstanding these two power-saving states? Theoretically I think you're right, but in current qemu S3 does a hardware reset without reseting the memory, so kind of a sleep + immediate wakeup. S4 is emulated correctly - qemu doesn't have to do anything special. > > > > > The decision to use the RTC Wakeup mechanism to resume the host from > > sleep was taken in [1]. An initial API was discussed in [2]. > > Some design ideas for the asynchronous mechanism implementation was > > discussed in [3]. > > > > v3: > > * Rebased to libvirt 0.9.7 > > * Added a check to see if alarmTime (suspend duration) is within an > > acceptable range. > > > > v2: > > * Added an init function which finds out if S3/S4 is supported by the host, > > upon the first request to suspend/hibernate. > > * Added synchronization/locking to ensure that only one suspend operation > > is active at a time. > > > > v1: http://www.redhat.com/archives/libvir-list/2011-September/msg00830.html > > v2: http://comments.gmane.org/gmane.comp.emulators.libvirt/46729 > > > > References: > > [1]. http://www.redhat.com/archives/libvir-list/2011-August/msg00327.html > > [2]. http://www.redhat.com/archives/libvir-list/2011-August/msg00248.html > > [3]. http://www.redhat.com/archives/libvir-list/2011-September/msg00438.html > > [4]. http://www.redhat.com/archives/libvir-list/2011-November/msg00378.html > > > > -- > Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list