From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd7Oa-0003da-KT for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:38:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd7OZ-0001yC-D6 for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:38:48 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:41631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd7OZ-0001xs-9h for qemu-devel@nongnu.org; Tue, 20 Dec 2011 16:38:47 -0500 Received: by iagj37 with SMTP id j37so12181714iag.4 for ; Tue, 20 Dec 2011 13:38:46 -0800 (PST) Message-ID: <4EF10062.5090302@codemonkey.ws> Date: Tue, 20 Dec 2011 15:38:42 -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> In-Reply-To: <4EF0FCC6.5020705@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 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 >