From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd9Jq-00058H-Kj for qemu-devel@nongnu.org; Tue, 20 Dec 2011 18:42:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd9Jp-0006iS-5M for qemu-devel@nongnu.org; Tue, 20 Dec 2011 18:42:02 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:56682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd9Jp-0006iJ-28 for qemu-devel@nongnu.org; Tue, 20 Dec 2011 18:42:01 -0500 Received: by iagj37 with SMTP id j37so12349899iag.4 for ; Tue, 20 Dec 2011 15:42:00 -0800 (PST) Message-ID: <4EF11D44.6060502@codemonkey.ws> Date: Tue, 20 Dec 2011 17:41:56 -0600 From: Anthony Liguori 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> <4EF10212.6060205@web.de> <4EF1045C.7090809@codemonkey.ws> <4EF10A2F.6070502@web.de> In-Reply-To: <4EF10A2F.6070502@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Jan Kiszka Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini 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 change >> 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. Yes, but that's not what I was getting at. I think you are currently planning on enabling/disabling the in-kernel apic through a machine option? Where I'd like to get to is that the CPUs are modeled as devices and whether the APIC is in-kernel or not is a property of the CPU (just like any other CPU flag). For something like the i8254, since that's a child of the PIIX3, it would be a property of the PIIX3 which it would use to create the appropriate i8254 type. You could also have the CPU and/or i8254 have a link<> which would allow a user to explicitly instantiate the appropriate device but I think that makes it harder to use than it should be. By making it a property of the composition parent, you let the parent make the best choice to start with and then a user has the ability to override it if it sees fit to. Regards, Anthony Liguori > Jan >