From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcoVA-00046g-IF for qemu-devel@nongnu.org; Mon, 19 Dec 2011 20:28:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcoV9-00010Z-1n for qemu-devel@nongnu.org; Mon, 19 Dec 2011 20:28:20 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:48674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcoV8-00010V-MA for qemu-devel@nongnu.org; Mon, 19 Dec 2011 20:28:19 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id 0E5E61BCB9843 for ; Tue, 20 Dec 2011 02:28:18 +0100 (CET) Message-ID: <4EEFE4A0.9050306@web.de> Date: Tue, 20 Dec 2011 02:28:00 +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> <4EEFE2BD.2090201@web.de> In-Reply-To: <4EEFE2BD.2090201@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7987F4F73BE4B9105EF5C1A6" 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) --------------enig7987F4F73BE4B9105EF5C1A6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-20 02:19, Jan Kiszka wrote: > 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 thro= ugh >>>>>>> uq/master. Still, your review is needed. >>>>>> >>>>>> Overall, it looks good except for the backend/frontend split. Thi= s >>>>>> 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 onl= y >>>>> 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 nam= e. >>>> >>>> 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/8259= 8 >>> for the discussion of that model. >> >> 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. >> >> 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). >> >> 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 ha= ve >> 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 mer= ge. >> >> I don't see any compatibility issues here so I'm not really concerned >> about introducing a regression by breaking it into two devices. >=20 > I don't want to see yet another attempt merged that requires foreseeabl= e > refactoring later on. The point of this one is to do it in a way that i= s > providing a sound foundation for all those other features that still > wait in qemu-kvm for refactoring. >=20 > The point is that migration support between in-kernel on/off is a > worthwhile feature we should design for. Forgot to state the why: This allows seamless migration from older, non-accelerated setups and to switch between both models in case on faces some issues. That not only applies to the APIC but to all those various in-kernel device models we have and will add in the future. > 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 ca= n > address APICs, IOAPICs, i8259, i8254 and all the chips that non-x86 wil= l > bring us without knowing where they are implemented and without worryin= g > 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. >=20 > Jan Jan --------------enig7987F4F73BE4B9105EF5C1A6 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/ iEYEARECAAYFAk7v5KAACgkQitSsb3rl5xRJswCfZGpQL5/HnEr2QZk5NM8iNyrw yVMAoJt0jyVE/YZww/COke55CxVLBeYh =OhTw -----END PGP SIGNATURE----- --------------enig7987F4F73BE4B9105EF5C1A6--