From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrwou-0007NF-Ng for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:09:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrwoq-0007Jk-PO for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:09:40 -0400 Received: from [199.232.76.173] (port=44697 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrwoq-0007JM-86 for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:09:36 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:47579) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lrwop-0007ce-MJ for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:09:35 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39G95dM020500 for ; Thu, 9 Apr 2009 10:09:05 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39G9RSv064028 for ; Thu, 9 Apr 2009 10:09:27 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39G9Ro6028271 for ; Thu, 9 Apr 2009 10:09:27 -0600 Message-ID: <49DE1DB3.30402@us.ibm.com> Date: Thu, 09 Apr 2009 11:09:23 -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> <49DDF807.1050707@us.ibm.com> <49DDFAD5.7060808@redhat.com> <49DDFC5C.4080504@us.ibm.com> <49DE0042.9050103@redhat.com> <49DE0271.8090103@us.ibm.com> <49DE05F2.5060304@redhat.com> <49DE0673.3070501@us.ibm.com> <49DE081D.1030702@redhat.com> <49DE0CF2.3060307@us.ibm.com> <49DE1029.3030909@redhat.com> <49DE16DE.6030206@us.ibm.com> <49DE1AD2.2060600@redhat.com> In-Reply-To: <49DE1AD2.2060600@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: > Suppose you have a command which changes the meaning of a > notification. If a notification arrives before the command > completion, then it happened before the command was executed. If you want to make that reliable, you cannot have multiple monitors. Since you can mask notifications, there can be an arbitrarily long time between notification and the event happening. Socket buffering presents the same problem. Image: Monitor 1: time 0: (qemu) hotadd_cpu 2 time 1: (qemu) hello world time 5: time 6: notification: cpu 2 added time 6: (qemu) Monitor 2: time 3: (qemu) hotremove_cpu 2 time 4: (qemu) time 5: notification: cpu 2 removed time 6: (qemu) So to eliminate this, you have to ban multiple monitors. Fine, let's say we did that, it's *still* racy because at time 3, the guest may hot remove cpu 2 on it's own since the guests VCPUs get to run in parallel to the monitor. And even if you somehow eliminate the issue around masking notifications, you still have socket buffering that introduces the same problem. The best you can do is stick a time stamp on a notification and make sure the management tool understands that the notification is reflectively of the state when the event happened, not of the current state. FWIW, this problem is not at all unique to QEMU and is generally true of most protocols that support an out-of-band notification mechanism. -- Regards, Anthony Liguori