From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd7VZ-0006Io-Dh for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:46:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd7VW-0003By-4O for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:46:01 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:54579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd7VV-0003Bd-Pe for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:45:58 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id 527BF1AD1F298 for ; Tue, 20 Dec 2011 22:45:56 +0100 (CET) Message-ID: <4EF10212.6060205@web.de> Date: Tue, 20 Dec 2011 22:45:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4EEFB72E.7030508@codemonkey.ws> <4EEFC970.9030205@web.de> <4EEFD69F.6080700@codemonkey.ws> <4EEFD786.8030609@web.de> <4EEFD90A.1000204@codemonkey.ws> <4EF05BC4.8010905@redhat.com> <4EF09078.2030508@codemonkey.ws> <4EF092D2.6080009@redhat.com> <4EF0937D.3090207@codemonkey.ws> <4EF09453.3030505@redhat.com> <4EF096AC.4070803@codemonkey.ws> <4EF0BFB5.6060502@siemens.com> <4EF0DE93.5000306@codemonkey.ws> <4EF0FCC6.5020705@web.de> <4EF10062.5090302@codemonkey.ws> In-Reply-To: <4EF10062.5090302@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F16DAA8587A6638F48E128F" Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F16DAA8587A6638F48E128F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-20 22:38, Anthony Liguori wrote: > On 12/20/2011 03:23 PM, Jan Kiszka wrote: >> On 2011-12-20 20:14, Anthony Liguori wrote: >>> On 12/20/2011 11:02 AM, Jan Kiszka wrote: >>>> On 2011-12-20 15:07, Anthony Liguori wrote: >>>>> On 12/20/2011 07:57 AM, Paolo Bonzini wrote: >>>>>> On 12/20/2011 02:54 PM, Anthony Liguori wrote: >>>>>>>> In QOM parlance Jan implemented this: >>>>>>>> >>>>>>>> abstract class Object >>>>>>>> abstract class Device >>>>>>>> class APIC: { backend: link } >>>>>>>> abstract class APICBackend >>>>>>>> class QEMU_APICBackend >>>>>>>> class KVM_APICBackend >>>>>>> >>>>>>> I don't fundamentally object to modeling it like this provided th= at >>>>>>> it's >>>>>>> modeled (and visible) through qdev and not done through a one-off= >>>>>>> infrastructure. >>>>>> >>>>>> There is no superclass of DeviceState, hence doing it through qdev= >>>>>> would mean >>>>>> introducing a new bus type and so on. This would be a superb examp= le >>>>>> of a >>>>>> useless bus that can disappear with QOM, but I don't see why we >>>>>> should >>>>>> take the >>>>>> pain to add it in the first place. :) >>>>> >>>>> Right, so let's modeled it for now as inheritance which qdev can co= pe >>>>> with. >>>> >>>> Do we have a clear plan now how to sort out the addressing issues in= >>>> this model? I mean when registering two devices under different name= s >>>> that are supposed to be addressable under the same alias once >>>> instantiated. I didn't follow recent qtree naming changes in details= >>>> unfortunately, if they already enable this. >>> >>> I think everyone is in agreement. We'll start with an APICBase type >>> that's modeled in qdev as a base class. >>> >>> There will be an APICBaseInfo that will replace APICBackend. >>> >>> There will be two classes that implement APICBaseInfo, KvmAPIC and >>> APIC. They will be separate devices. >>> >>> APICBase will register the vmsd and will use the name "apic" to regis= ter >>> it. You can just set the qdev.vmsd field in the apic_qdev_register() >>> function to ensure that both use the same implementation. >> >> I'm not talking about migration here, I'm talking about qtree >> addressability. That is orthogonal, at least right now. >=20 > qtree is not an ABI. The output of info qtree can (and will) change > over time. That's not the point. The point is that at least some branch of the qtree should be identically named for both the KVM and the user space incarnations of a particular device (given a certain qemu version). The request was that /qtree/path/to/apic should not change if you enable KVM in-kernel acceleration in the very same qemu release. There can also be some /qtree/path/to/kvm-apic then, but as alias (or as primary name and the other becomes an alias). I think this makes sense if the user is still able to clearly differentiate between both versions when listing devices. Jan --------------enig6F16DAA8587A6638F48E128F 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/ iEUEARECAAYFAk7xAhIACgkQitSsb3rl5xSEDwCYgkjb+OOnkGxNGfW7Oyg8kon3 9gCfbkY5il/kEdDjC0+sU1DWsix//uw= =pRCd -----END PGP SIGNATURE----- --------------enig6F16DAA8587A6638F48E128F--