
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