From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse Date: Tue, 20 Dec 2011 17:41:56 -0600 Message-ID: <4EF11D44.6060502@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini To: Jan Kiszka Return-path: Received: from mail-gx0-f174.google.com ([209.85.161.174]:61422 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753280Ab1LTXmA (ORCPT ); Tue, 20 Dec 2011 18:42:00 -0500 Received: by ggdk6 with SMTP id k6so5154939ggd.19 for ; Tue, 20 Dec 2011 15:42:00 -0800 (PST) In-Reply-To: <4EF10A2F.6070502@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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 >