From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rcnml-0003ZO-Dx for qemu-devel@nongnu.org; Mon, 19 Dec 2011 19:42:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rcnmk-00036U-Ac for qemu-devel@nongnu.org; Mon, 19 Dec 2011 19:42:27 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:42372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rcnmk-00036Q-5f for qemu-devel@nongnu.org; Mon, 19 Dec 2011 19:42:26 -0500 Received: by ggnk1 with SMTP id k1so5074134ggn.4 for ; Mon, 19 Dec 2011 16:42:25 -0800 (PST) Message-ID: <4EEFD9EE.9010709@codemonkey.ws> Date: Mon, 19 Dec 2011 18:42:22 -0600 From: Anthony Liguori 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> In-Reply-To: <4EEFD8D1.3060707@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Jan Kiszka Cc: Lai Jiangshan , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity On 12/19/2011 06:37 PM, Jan Kiszka wrote: > On 2011-12-20 01:32, Anthony Liguori wrote: >> On 12/19/2011 05:49 PM, Jan Kiszka wrote: >>> On 2011-12-19 23:24, Anthony Liguori wrote: >>>> On 12/19/2011 03:17 PM, Marcelo Tosatti wrote: >>>>> >>>>> Anthony, >>>>> >>>>> Can you please review& ACK? >>>>> >>>>> You could even apply directly but well do a kvm-autotest run through >>>>> uq/master. Still, your review is needed. >>>> >>>> Overall, it looks good except for the backend/frontend split. This >>>> should be done in terms of qdev inheritance. >>> >>> I cannot follow your idea here yet. There is no inheritance as we end up >>> with only a single class that permutes (selects a different backend) on >>> creation. I'm not sure how to model two classes that will still only >>> mean a single qdev registration. >> >> See other reply in thread. >> >> We should model this as two separate qdev devices. We can avoid >> regressing migration in qemu-kvm by just having a common vmstate name. >> >> apic is a no-user device so there's no way that changing the name of it >> in qemu-kvm can affect users. > > 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. 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). Regards, Anthony Liguori > > Jan >