From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuzLC-0001DK-UF for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:32:06 -0400 Received: from [140.186.70.92] (port=53467 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuzLA-0001DC-U8 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:32:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuzL9-0002RE-4n for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:32:04 -0400 Received: from mail2.shareable.org ([80.68.89.115]:33748) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuzL8-0002R8-UT for qemu-devel@nongnu.org; Thu, 25 Mar 2010 22:32:03 -0400 Date: Fri, 26 Mar 2010 02:31:59 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt Message-ID: <20100326023159.GL19308@shareable.org> References: <4BA7C40C.2040505@codemonkey.ws> <4BA900F1.5020001@redhat.com> <4BA916FC.2000607@codemonkey.ws> <4BA99AAE.5040702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA99AAE.5040702@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "libvir-list@redhat.com" , qemu-devel Avi Kivity wrote: > On 03/23/2010 09:31 PM, Anthony Liguori wrote: > > > >> > >>One problem is that this is libvirt version specific. For example, > >>libvirt x doesn't support spice so we control that thorough qmp. But > >>libvirt x+1 does support spice and now it gets confused about all the > >>spice messages. > > > >That's only a problem if we only support a single QMP session. This > >is exactly why we need to support multiple QMP sessions (and do). > > It's unrelated to the number of sessions. libvirt expects state that it > manages in qemu not to change randomly. Users know that, so they will > only manage non-libvirt state in their private session. But a new > version of libvirt may expand its scope and start managing this area, > leading to conflicts. We have events when state changes, for libvirt to be informed. But that's prone to race conditions. A fairly universal solution to that is "pre"-events, where something that's going to change state emits a pre-event, waits for an ack from all listeners, then proceeds or not according to the acks, then finally emits the post-event to say the state is changed. Between pre and post events, as far as the listener is concerned, the state is uncertain and it must query or wait when it needs the value.(*) In other words, libvirt would register to listen to all the pre-events for state that it cares about being synchronised with. When libvirt expands its scope, it would simply listen to some more. -- Jamie (*) Yes, this is like 2-phase transactions, and it's also a bit like MESI caching. But it's easier to understand than both :-)