From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrx95-0000J5-8o for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:30:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrx90-0000EK-GU for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:30:30 -0400 Received: from [199.232.76.173] (port=41649 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrx90-0000E6-6V for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:30:26 -0400 Received: from mx2.redhat.com ([66.187.237.31]:41487) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lrx8z-0002rA-M7 for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:30:26 -0400 Message-ID: <49DE229B.7050408@redhat.com> Date: Thu, 09 Apr 2009 19:30:19 +0300 From: Avi Kivity 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> <49DE1DB3.30402@us.ibm.com> In-Reply-To: <49DE1DB3.30402@us.ibm.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: Anthony Liguori Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard Anthony Liguori wrote: > 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. Right. > 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. Well, not ban multiple monitors, but require that for non-racy operation commands and notifications be on the same session. We can still debug on our dev-only monitor. > 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. A guest can't hotremove a vcpu. It may offline a vcpu, but that's not the same. Obviously, if both the guest and the management application can initiate the same action, then there will be races. But I don't think that's how things should be -- the guest should request a vcpu to be removed (or added), management thinks and files forms in triplicate, then hotadds or hotremoves the vcpu (most likely after it is no longer needed). With the proper beaurocracy, there is no race. > > And even if you somehow eliminate the issue around masking > notifications, you still have socket buffering that introduces the > same problem. If you have one monitor, the problem is much simpler, since events travelling in the same direction (command acknowledge and a notification) cannot be reordered. With a command+wait, the problem is inherent. > > 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. Timestamps are really bad. They don't work at all if the management application is not on the same host. They work badly if it is on the same host, since commands and events will be timestamped at different processes. > 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. > command+wait makes it worse. Let's stick with established practice. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.