On Mon, Dec 12, 2011 at 11:29 AM, Gerd Hoffmann <kra...@redhat.com> wrote: > On 12/12/11 11:18, Stefan Hajnoczi wrote: >> On Sun, Dec 11, 2011 at 10:29 AM, Alon Levy <al...@redhat.com> wrote: >>> On Thu, Dec 08, 2011 at 05:45:44PM -0200, Luiz Capitulino wrote: >>>> Hi there, >>>> >>>> I'm about to completely drop the MONITOR_CMD_ASYNC API, but it turns out >>>> that >>>> the command client_migrate_info uses it. That's a legacy interface and has >>>> to >>>> be dropped, no command should be using it... >>>> >>>> Something tells me that if I just drop it (and change the command to use >>>> the >>>> regular interface), bad things will happen. Am I right? :) >>>> >>> >>> The monitor command client_migrate_info needs to complete after getting >>> an ACK message from the currently connected spice client (this is the >>> only case where this is required - if there is no client then the >>> MONITOR_CMD_ASYNC API won't be used). This in turn requires the main >>> thread to perform select and call the callback that will process this >>> ACK. That's why the MONITOR_CMD_ASYNC API was used. >>> >>> I'm not aware of any other way to do this, I'll be glad for any help >>> here. Also, I understand this is not what is not true async, since one >>> would expect a true async interface to support multiple in flight >>> monitor commands. If there is any ETA or existing way to do this we >>> could change the implementation of client_migrate_info. >> >> Is it possible to use a QMP event to signal completion instead of a >> MONITOR_CMD_ASYNC command? > > Problem is this breaks the qemu <-> libvirt interface.
I had the same issue with the block_job_cancel command, which Adam Litke and Eric Blake helped us fix and find a backward-compatible libvirt solution for: http://www.redhat.com/archives/libvir-list/2011-November/msg01351.html Stefan
