From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LruJL-0007GC-Vv for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:28:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LruJH-0007EU-8w for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:28:55 -0400 Received: from [199.232.76.173] (port=58823 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LruJH-0007EQ-5m for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:28:51 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:58051) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LruJG-0007K0-N3 for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:28:50 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39DPHvb010973 for ; Thu, 9 Apr 2009 09:25:17 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39DShJH190118 for ; Thu, 9 Apr 2009 09:28:43 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39DSgg3013016 for ; Thu, 9 Apr 2009 09:28:42 -0400 Message-ID: <49DDF807.1050707@us.ibm.com> Date: Thu, 09 Apr 2009 08:28:39 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <49DDAF9F.7040400@redhat.com> In-Reply-To: <49DDAF9F.7040400@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: >> Right now only one monitor device can be enabled at a time. In order >> to support >> asynchronous notification of events, I would like to introduce a >> 'wait' command >> that waits for an event to occur. This implies that we need an >> additional >> monitor session to allow commands to still be executed while waiting >> for an >> asynchronous notification. >> >> > > I think this is race prone. For example: > > monitor 1: wait > > monitor 2: hotunplug dev1 > monitor 2: hotplug dev1 > > monitor 1: event > > there is no way to tell whether event (which relates to dev1) happened > the hotunplug or after the hotunplug. In general there is no way to > correlate events to commands. events don't correlate to commands. Can you give an example of why you'd want to correlate and event to a command. > What's wrong with having async notifications? Isn't this async notifications? > Sure, we'll need to make sure notifications don't mix with command > responses, and that all commands are acked (the (qemu) prompt serves > that purpose now), but it seems to me do be a lot easier for the > management end. FWIW, you can have asynchronous completion of monitor commands. See migration as an example. The (qemu) prompt is the ack that the command is finished. You can only have one async command per monitor session which is why you need multiple monitors. If we had a non-human monitor mode, I think it would be fine to have many monitors multiplexed over a single channel. The internal monitor abstraction doesn't change. I think multiplexing multiple monitor sessions requires a non-human mode because you need to tag all output, etc. which is what we need for non-human mode anyway. -- Regards, Anthony Liguori