From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd79j-0008Jj-U8 for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:23:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd79i-0007YO-Fl for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:23:27 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:51753) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd79i-0007YI-3X for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:23:26 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id CBBBC1BD0C3C6 for ; Tue, 20 Dec 2011 22:23:24 +0100 (CET) Message-ID: <4EF0FCC6.5020705@web.de> Date: Tue, 20 Dec 2011 22:23:18 +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> In-Reply-To: <4EF0DE93.5000306@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig192308E04523B793EB02CBE6" 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) --------------enig192308E04523B793EB02CBE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 that= >>>>> 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 example= >>>> of a >>>> useless bus that can disappear with QOM, but I don't see why we shou= ld >>>> take the >>>> pain to add it in the first place. :) >>> >>> Right, so let's modeled it for now as inheritance which qdev can cope= >>> 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 names >> 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. >=20 > I think everyone is in agreement. We'll start with an APICBase type > that's modeled in qdev as a base class. >=20 > There will be an APICBaseInfo that will replace APICBackend. >=20 > There will be two classes that implement APICBaseInfo, KvmAPIC and > APIC. They will be separate devices. >=20 > APICBase will register the vmsd and will use the name "apic" to registe= r > 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 >> >> This does not need to be implemented before merge. I just like to have= a >> common view on how to address it once it matters (for device inspectio= n). >=20 > You can do this all today without any pending patches. Nope, don't see how. There is currently no use case for it (e.g. no device_show - device_add/del makes no sense for the devices in question), but it should be addressable in QOM in the future. Jan --------------enig192308E04523B793EB02CBE6 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/ iEYEARECAAYFAk7w/MkACgkQitSsb3rl5xTAjgCfW+ndOziLUy5EGJN2wFYRdsOI wuQAnRSXge1qlAnQrszjSkLEIE01f3s/ =QGb+ -----END PGP SIGNATURE----- --------------enig192308E04523B793EB02CBE6--