Re: [Qemu-devel] [PATCH v9 0/6] monitor: enable OOB by default

[Eric Blake <eblake@redhat.com>]

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-armbru@redhat.com>
>> Based-on: <20180901111716.1675-1-armbru@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