From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse Date: Wed, 21 Dec 2011 00:45:43 +0100 Message-ID: <4EF11E27.20704@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> <4EF10A2F.6070502@web.de> <4EF11D44.6060502@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig287EEF6E0B7C4EBEC7D5FF4E" Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini To: Anthony Liguori Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:34311 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753437Ab1LTXpv (ORCPT ); Tue, 20 Dec 2011 18:45:51 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate03.web.de (Postfix) with ESMTP id 7225E1AD25B5B for ; Wed, 21 Dec 2011 00:45:49 +0100 (CET) In-Reply-To: <4EF11D44.6060502@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig287EEF6E0B7C4EBEC7D5FF4E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-12-21 00:41, Anthony Liguori wrote: > On 12/20/2011 04:20 PM, Jan Kiszka wrote: >> On 2011-12-20 22:55, Anthony Liguori wrote: >>> 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= : >>> >>> /cpus/cpu0/apic >>> /cpus/cpu1/apic >>> >>> Which would be links on the composition tree. The name wouldn't chan= ge >>> even if the type of this object changed. >> >> 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= is >>> created as a kvm-apic or just a normal apic. >> >> I rather hope you will be able to ask the device for its type instead >> replicating that information. >=20 > Yes, but that's not what I was getting at. >=20 > I think you are currently planning on enabling/disabling the in-kernel > apic through a machine option? Yes, because it is a VM-wide flag, nothing you can control per irqchip, per chipset or whatever. It must be consistent for the whole VM, means all CPUs, the chipset, the IOAPIC (which may or may not (PIIX3) be part of it) etc. It also affects KVM internals that are not directly bound to device models. Jan --------------enig287EEF6E0B7C4EBEC7D5FF4E 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/ iEYEARECAAYFAk7xHioACgkQitSsb3rl5xQsEQCgrzU+3uHZWiQbqgmcVEZKwRDg WG4AnRclCv391WgrVIn6HLJTte6EXvie =aozP -----END PGP SIGNATURE----- --------------enig287EEF6E0B7C4EBEC7D5FF4E--