[libvirt] Re: [Qemu-devel] [PATCH 2/6] Introduce monitor 'wait' command (v2)

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> The wait command will pause the monitor the command was issued in 
>> until a new
>> event becomes available.  Events are queued if there isn't a waiter 
>> present.
>> The wait command completes after a single event is available.
>>   
>
> How do you stop a wait if there are no pending events?

You mean, cancel a wait?  You cannot.  I thought about whether it was a 
problem or not.  I'm not sure.

You could introduce a wait-cancel command, but then you need a way to 
identify which wait you want to cancel.  I can't think of a simple way 
to do that today.

>> Today, we queue events indefinitely but in the future, I suspect 
>> we'll drop
>> events that are older than a certain amount of time to avoid infinitely
>> allocating memory for long running VMs.
>>   
>
> This queueing plug the race where an event happens immediately after a 
> wait completes.  But it could be avoided completely by having 
> asynchronous notifications on a single monitor.

There are multiple things I think are being confused: asynchronous 
completion of monitor commands, events, monitor multiplexing, and 
non-human mode.

There can only be one command active at any given time on a Monitor 
context.  We can have many Monitor contexts.  There is currently only 
one Monitor context connected to a character device at a given time.

I think what you want to see is something like this:

<input> tag=4: info cpus
<input> tag=5: info kvm
<output> tag=5,rc=0: kvm enabled
<output> tag=4,rc=0: eip = 0x0000000444
<ouput> rc=0,class=vm-state,name=start: vm started

To me, this is a combination of events, which is introduced by this 
patch, a non-human monitor mode, and finally multiplexing multiple 
monitors into a single session.

Right now, you can have the same functional thing by having three 
monitors.  In the first monitor you'd see:

(qemu) info cpus
eip = 0x000000444
(qemu)

In the second you'd see:

(qemu) info kvm
kvm enabled
(qemu)

In the third you'd see:

(qemu) wait
23423423.23423: vm-state: start: vm started
(qemu)

Even those the two info commands today are synchronous, there's nothing 
requiring them to be (see migrate as an example).  So I think we're in 
agreement but you just want to jump ahead 6 months ;-)

-- 
Regards,

Anthony Liguori