From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd58z-0000lc-EP for qemu-devel@nongnu.org; Tue, 20 Dec 2011 14:14:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd58x-00077V-Up for qemu-devel@nongnu.org; Tue, 20 Dec 2011 14:14:33 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:33730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd58x-00077P-Ph for qemu-devel@nongnu.org; Tue, 20 Dec 2011 14:14:31 -0500 Received: by ggnk1 with SMTP id k1so5752071ggn.4 for ; Tue, 20 Dec 2011 11:14:31 -0800 (PST) Message-ID: <4EF0DE93.5000306@codemonkey.ws> Date: Tue, 20 Dec 2011 13:14:27 -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> In-Reply-To: <4EF0BFB5.6060502@siemens.com> 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 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 should >>> 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. I think everyone is in agreement. We'll start with an APICBase type that's modeled in qdev as a base class. There will be an APICBaseInfo that will replace APICBackend. There will be two classes that implement APICBaseInfo, KvmAPIC and APIC. They will be separate devices. APICBase will register the vmsd and will use the name "apic" to register it. You can just set the qdev.vmsd field in the apic_qdev_register() function to ensure that both use the same implementation. > > 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 inspection). You can do this all today without any pending patches. As I mentioned earlier, I don't mind doing this after the fact if you'd just like to get the current series merged. If your series lands before the QOM series I just posted, then I will need to do it as part of the QOM series anyway. Regards, Anthony Liguori > Jan >