From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse Date: Tue, 20 Dec 2011 23:20:31 +0100 Message-ID: <4EF10A2F.6070502@web.de> 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> <4EF10212.6060205@web.de> <4EF1045C.7090809@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30AAB1EEBE2B93D45D8D7B38" Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini To: Anthony Liguori Return-path: In-Reply-To: <4EF1045C.7090809@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30AAB1EEBE2B93D45D8D7B38 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-20 22:55, Anthony Liguori wrote: > On 12/20/2011 03:45 PM, Jan Kiszka wrote: >> On 2011-12-20 22:38, Anthony Liguori wrote: >>>> I'm not talking about migration here, I'm talking about qtree >>>> addressability. That is orthogonal, at least right now. >>> >>> 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). >=20 > There is no such thing as "qtree paths". Today, devices have ids or ar= e > anonymous. The apic is currently an anonymous device and there's no wa= y > to address it until we complete the PC composition tree. I have patche= s > for this, but that won't land until after series 4. >=20 > Starting right now, we have a standard path mechanism. This path will > either follow the composition tree or potentially an arbitrary path > through the link graph. >=20 > The components of the path are the *property* names of the parent > device. In the case of the local APIC, you would have something like: >=20 > /cpus/cpu0/apic > /cpus/cpu1/apic >=20 > Which would be links on the composition tree. The name wouldn't change= > even if the type of this object changed.=20 Perfect! That was what I forgot about and what makes it possible to return to the original two-device model. > You'll probably have a flag or > something in the cpu object that lets you determine whether the child i= s > created as a kvm-apic or just a normal apic.=20 I rather hope you will be able to ask the device for its type instead replicating that information. Jan --------------enig30AAB1EEBE2B93D45D8D7B38 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/ iEYEARECAAYFAk7xCi8ACgkQitSsb3rl5xSRPwCgr/H215NP6kceJq0nzIKeQTGY b+oAnig7opSlcZA4QPtk/6wbnNfLDyhp =XHkL -----END PGP SIGNATURE----- --------------enig30AAB1EEBE2B93D45D8D7B38--