Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse

[Anthony Liguori <anthony@codemonkey.ws>]

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<APICBackend>   }
>>>>>>> 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
>