On 10/10/18 11:26 AM, Eric Blake wrote:
On 10/9/18 1:27 AM, Peter Xu wrote:
Based-on: <20180828191048.29806-1-arm...@redhat.com>
Based-on: <20180901111716.1675-1-arm...@redhat.com>
(this series is based on Markus's monitor-next tree)
v9:
- add r-bs
- release the qmp queue lock before resume [Marc-Andre]
I haven't reviewed closely, but did want to report that I tested that
with your patches applied, there is no way to trigger OOB of the initial
capability handshake (good). It's a bit odd that the initial error
(input member unexpected) is different from the later error (does not
support OOB), but not a show-stopper, so I don't think you need to worry
about it:
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 3},
"package": "v3.0.0-1150-g7d932cd3d53"}, "capabilities": ["oob"]}}
{"exec-oob":"qmp_capabilities","arguments":{"enable":["oob"]}}
{"error": {"class": "GenericError", "desc": "QMP input member 'exec-oob'
is unexpected"}}
{"execute":"qmp_capabilities","arguments":{"enable":["oob"]}}
{"return": {}}
{"exec-oob":"qmp_capabilities"}
{"error": {"class": "GenericError", "desc": "The command
qmp_capabilities does not support OOB"}}
On the other hand, when I'm trying to use a qemu binary with these
patches applied, libvirt is hanging when trying to probe the
capabilities of the binary, waiting for a response to
"qmp_capabilities". I'll try and bisect which patch is causing the
problem, and figure out why it is happening for libvirt and not running
by hand (perhaps is it a tty vs. Unix socket thing?)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
