From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcoNG-0001rL-Is for qemu-devel@nongnu.org; Mon, 19 Dec 2011 20:20:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcoNF-00087a-9f for qemu-devel@nongnu.org; Mon, 19 Dec 2011 20:20:10 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:42111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcoNE-000874-U3 for qemu-devel@nongnu.org; Mon, 19 Dec 2011 20:20:09 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id 4925F1BCB5673 for ; Tue, 20 Dec 2011 02:20:07 +0100 (CET) Message-ID: <4EEFE2BD.2090201@web.de> Date: Tue, 20 Dec 2011 02:19:57 +0100 From: Jan Kiszka 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> <4EEFDFFE.6000402@codemonkey.ws> In-Reply-To: <4EEFDFFE.6000402@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig914BC610066A35F5C7A4CE2B" 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 , Avi Kivity This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig914BC610066A35F5C7A4CE2B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-20 02:08, Anthony Liguori wrote: > 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 throu= gh >>>>>> 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= =2E >>> >>> 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. >=20 > Let me say that I know this is the last bit of qemu-kvm that needs > merging and that this has been an epic effort. I wouldn't refuse to > merge a pull request that came in with this in its current form. >=20 > If we merged this now, I would be submitting patches in the not too > distant future to remove all of this backend stuff in favor of proper > modeling (including using two separate devices). >=20 > There's lot of inconsistency in qdev already today so adding a little > more isn't the end of the world. We're going to need to eventually hav= e > this debate soon so it's up to you whether you want to just get this > merged now and worry about this another day or resolve this before merg= e. >=20 > I don't see any compatibility issues here so I'm not really concerned > about introducing a regression by breaking it into two devices. I don't want to see yet another attempt merged that requires foreseeable refactoring later on. The point of this one is to do it in a way that is providing a sound foundation for all those other features that still wait in qemu-kvm for refactoring. The point is that migration support between in-kernel on/off is a worthwhile feature we should design for. That either means skipping the backend property on device tree migration (maybe a feature we want in other use cases as well) or provide an alias naming scheme where you can address APICs, IOAPICs, i8259, i8254 and all the chips that non-x86 will bring us without knowing where they are implemented and without worrying to migrate between those variants. If you have a good model for that in mind, rolling back to v1, rebasing improvements from v5 over it would not be a big deal. But everyone in this round should agree on this first. I don't wanna port back and forth nor refactor all this again when once it's in. Jan --------------enig914BC610066A35F5C7A4CE2B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7v4r0ACgkQitSsb3rl5xS1vQCePM+/GhdFRjlOxdTaYWAacJ5D iCMAniOVy9+VZQCzztJohW/KQwEkMut6 =Hzay -----END PGP SIGNATURE----- --------------enig914BC610066A35F5C7A4CE2B--