On Thu, Apr 11, 2019 at 10:25:11 +0200, Michal Privoznik wrote:
This capability tells whether qemu is capable of waking up the
guest from PM suspend.
Based-on-work-of: Daniel Henrique Barboza <danielhb413(a)gmail.com>
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 24 +++++++++++++++++++
src/qemu/qemu_capabilities.h | 3 +++
.../caps_4.0.0.riscv32.replies | 11 +++++++++
.../caps_4.0.0.riscv32.xml | 1 +
.../caps_4.0.0.riscv64.replies | 11 +++++++++
.../caps_4.0.0.riscv64.xml | 1 +
.../caps_4.0.0.x86_64.replies | 11 +++++++++
.../caps_4.0.0.x86_64.xml | 1 +
8 files changed, 63 insertions(+)
[...]
bool
virQEMUCapsCPUFilterFeatures(const char *name,
void *opaque)
@@ -4373,6 +4395,8 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
return -1;
if (virQEMUCapsProbeQMPSEVCapabilities(qemuCaps, mon) < 0)
return -1;
+ if (virQEMUCapsProbeQMPCurrentMachine(qemuCaps, mon) < 0)
+ return -1;
This seems wrong by definition. The function is supposed to query
current machine, but the capability lookup code uses 'none' machine
type. IIUC the support for wakeup in some cases depends on the presence
of ACPI in the guest and thus really can't be cached this way.
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
index aa9ee38c80..47ed75d359 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
@@ -21052,6 +21052,17 @@
}
}
+{
+ "execute": "query-current-machine",
+ "id": "libvirt-50"
+}
+
+{
+ "return": {
+ "wakeup-suspend-support": true
+ }
Did you gather this from an actual qemu run? I get the following when
using 'none' machine:
$ ./x86_64-softmmu/qemu-system-x86_64 -qmp stdio -machine none
{"QMP": {"version": {"qemu": {"micro": 92,
"minor": 1, "major": 3}, "package":
"v4.0.0-rc2-24-gbcdb5721dd"}, "capabilities": ["oob"]}}
VNC server running on ::1:5900
{"execute":"qmp_capabilities"}
{"return": {}}
{"execute":"query-current-machine"}
{"return": {"wakeup-suspend-support": false}}
Same result is with this patch applied.