From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrxLG-0005Hc-Ty for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:43:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrxLC-0005FH-2S for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:43:06 -0400 Received: from [199.232.76.173] (port=52985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrxLB-0005F7-N9 for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:43:01 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:47106) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrxLB-000541-6I for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:43:01 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39GfRfN021173 for ; Thu, 9 Apr 2009 10:41:27 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39GgjtE064642 for ; Thu, 9 Apr 2009 10:42:47 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39GgfaQ002456 for ; Thu, 9 Apr 2009 10:42:41 -0600 Message-ID: <49DE2580.2030507@us.ibm.com> Date: Thu, 09 Apr 2009 11:42:40 -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> <49DE1DB3.30402@us.ibm.com> <49DE229B.7050408@redhat.com> In-Reply-To: <49DE229B.7050408@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: >> 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. You still have the same basic problem: time 0: (qemu) notify-enable vnc-events time 1: (qemu) foo time 4: time 5: notification: client connected time 0: vnc client connects time 2: vnc client disconnects At time 5, when the management app gets the notification, it cannot make any assumptions about the state of the system. You still need timestamps. >> >> 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. Command acknowledge is not an event. Events are out-of-band. Command completions are in-band. Right now, they are synchronous and I expect that in the short term future, we'll have a non-human monitor mode that allows commands to be asynchronous. However, it's a mistake to muddle the distinction between an in-band completion and an out-of-band event. You cannot relate the out-of-band events commands. >> >> 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. Timestamps are relative, not absolutely. They should not be used to associate anything with the outside world. In fact, I have no problem making the timestamps relative to QEMU startup just to ensure that noone tries to do something silly like associate notification timestamps with system time. >> 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. What's the established practice? Do you know of any protocol that is line based that does notifications like this? IMAP IDLE is pretty close to "wait-forever". Regards, Anthony Liguori -- Regards, Anthony Liguori