From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LruUY-0004QF-4x for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:40:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LruUT-0004M8-Hu for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:40:29 -0400 Received: from [199.232.76.173] (port=38086 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LruUT-0004Lx-DT for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:40:25 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:57188) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LruUS-0000pS-Ve for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:40:25 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39Ddtf5014366 for ; Thu, 9 Apr 2009 07:39:55 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39DeNMo191602 for ; Thu, 9 Apr 2009 07:40:23 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39DeNju021647 for ; Thu, 9 Apr 2009 07:40:23 -0600 Message-ID: <49DDFAC6.6070708@us.ibm.com> Date: Thu, 09 Apr 2009 08:40:22 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/6] Introduce monitor 'wait' command (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <1239215702-23818-2-git-send-email-aliguori@us.ibm.com> <49DDD57F.7000807@redhat.com> In-Reply-To: <49DDD57F.7000807@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard 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: tag=4: info cpus tag=5: info kvm tag=5,rc=0: kvm enabled tag=4,rc=0: eip = 0x0000000444 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