From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcwWN-00049W-Kh for qemu-devel@nongnu.org; Tue, 20 Dec 2011 05:02:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcwWJ-0005ln-8O for qemu-devel@nongnu.org; Tue, 20 Dec 2011 05:02:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcwWI-0005lc-FH for qemu-devel@nongnu.org; Tue, 20 Dec 2011 05:02:03 -0500 Message-ID: <4EF05D10.8030708@redhat.com> Date: Tue, 20 Dec 2011 12:01:52 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111219211737.GA17469@amt.cnet> <4EEFB9AE.7050309@codemonkey.ws> <4EEFCD71.5040603@web.de> <4EEFD7A9.3050007@codemonkey.ws> <4EEFD8D1.3060707@web.de> <4EEFD9EE.9010709@codemonkey.ws> In-Reply-To: <4EEFD9EE.9010709@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Lai Jiangshan , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka On 12/20/2011 02:42 AM, Anthony Liguori wrote: >> Look down http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82598 >> for the discussion of that model. > > > I have. I don't understand the rationale for jumping through hoops here. > > There seems to be an assertion that migrating from in-kernel APIC to > userspace APIC is an important use case. I don't really see how > that's true. > That's only because no one is using qemu.git for virtualization. If they were, then you'd prevent existing users from using it, except through guest shutdown and relaunch of qemu (and perhaps reconfiguration). We've discussed removing the ioapic from the kernel. If we do that, then we need to support migration from in-kernel ioapic to userspace ioapic. > But nonetheless, the direction migration is heading is not just to > migrate the QOM path names to identify devices, but to provide a way > to introspect the device model, transfer the current device model > description to the other end, and create the device model on the > destination. > > This is the only way to reliably support things like hot-plug during > live migration which is something we punt to management tools (which > really can't implement it properly). > > So we'll already be migrating the apic backend property which means > that you are not going to have migration to and from in-kernel APIC > and userspace APIC without some sort of in-between translation layer > (which could just as easily change the device names). To what? The backend property should be private and not migrated. -- error compiling committee.c: too many arguments to function