On 4/11/19 8:43 AM, Peter Krempa wrote:
On 4/11/19 12:12 PM, Daniel Henrique Barboza wrote:
<snip/>
All that said, I think a good solution would be (2). dompmsuspend isn't a performance sensitive command, thus the extra time to execute the API can be ignored. Also, we can still check for QEMU_CAPS_QUERY_CURRENT_MACHINE inside qemuDomainPMSuspendForDuration to avoid firing up an error in a QEMU version that doesn't know the API. That's the thing. We can't. The capability doesn't exist yet. So every domain that is currently running thinks that qemu doesn't have the capability. And when updating libvirt to say next release only freshly started domains might/will have the capability. For all already running domains libvirt thinks the capability is not there. Only freshly started domains will get the capability. IOW, upgrading libvirt won't help you unless you restart your domains (might not want to do that). If you just go ahead with the PM suspend in case the capability bit for
On Thu, Apr 11, 2019 at 13:37:49 +0200, Michal Privoznik wrote: the presence of query-current-machine is not present you just will keep the existing behaviour. I think that is perfectly tolerable.
Error should be reported only if query-current-machine is supported and it returns false for wakeup-suspend-support. (Obviously also if our caps indicate that query-current-machine is supported but returns an error).
I agree with this approach. Michal, do you agree agree with this? If so, let me know if you plan to re-spin this series again. Otherwise I can do it. Thanks, DHB