[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC
Date: Mon, 12 Dec 2011 12:10:53 +0000

On Mon, Dec 12, 2011 at 11:29 AM, Gerd Hoffmann <address@hidden> wrote:
> On 12/12/11 11:18, Stefan Hajnoczi wrote:
>> On Sun, Dec 11, 2011 at 10:29 AM, Alon Levy <address@hidden> 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
> 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:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]