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 15:38:42 -0600 Message-ID: <4EF10062.5090302@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> 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-iy0-f174.google.com ([209.85.210.174]:33006 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752206Ab1LTVir (ORCPT ); Tue, 20 Dec 2011 16:38:47 -0500 Received: by iaeh11 with SMTP id h11so10803662iae.19 for ; Tue, 20 Dec 2011 13:38:46 -0800 (PST) In-Reply-To: <4EF0FCC6.5020705@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 12/20/2011 03:23 PM, Jan Kiszka wrote: > On 2011-12-20 20:14, Anthony Liguori wrote: >> 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. > > 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. > >> >>> >>> 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. > > Nope, don't see how. What is this issue? > > There is currently no use case for it (e.g. no device_show - > device_add/del makes no sense for the devices in question), but it > should be addressable in QOM in the future. I guess I'm a bit confused... Regards, Anthony Liguori > > Jan >