On 01/26/2012 07:31 AM, Michal Privoznik wrote: > On 26.01.2012 15:17, Eric Blake wrote: >> On 01/26/2012 07:06 AM, Michal Privoznik wrote: >>> define these flags: >>> >>> VIR_DOMAIN_SUSPEND_SLEEP = 0, /* Suspend to RAM */ >>> VIR_DOMAIN_SUSPEND_HIBERNATE = (1 << 0), /* Suspend to disk */ >> >> Not quite right. Our policy when fixing old APIs that forgot a flags >> argument is that the new API with flags 0 must be identical to the old >> API. Which means you need: >> >> VIR_DOMAIN_SUSPEND_PAUSE = 0, /* pause CPUs */ >> VIR_DOMAIN_SUSPEND_SLEEP = 1<<0, /* Suspend to RAM, power stays on */ > > Honestly, in case of virtual machines I can't see the difference between > these two. But okay, I'll rewrite it. VIR_DOMAIN_SUSPEND_PAUSE is what we have now, when you click the pause button in virt-manager - it means that qemu stops all guest CPUs, with no input from the guest. Resuming from this state requires virDomainResume to issue a monitor command. VIR_DOMAIN_SUSPEND_SLEEP involves the guest. S3 might be a very fast op with qemu, but it is not an instant op - the guest CPU continues to run, and the guest really does flush state to RAM. Furthermore, qemu is implementing S3 so that you can re-wake the guest via input (such as a keypress into a serial device, or a mouse click), with no intervening monitor command. That said, qemu is also implementing a new monitor command to wake up a guest that is in S3 state; so we _also_ need to add a new API virDomainResumeFlags, to give use the flexibility to expose that new monitor command. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list