On 2011-12-20 22:38, Anthony Liguori wrote:
> 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.That's not the point. The point is that at least some branch of the qtree should be identically named for both the KVM and the user space incarnations of a particular device (given a certain qemu version). The request was that /qtree/path/to/apic should not change if you enable KVM in-kernel acceleration in the very same qemu release. There can also be some /qtree/path/to/kvm-apic then, but as alias (or as primary name and the other becomes an alias). I think this makes sense if the user is still able to clearly differentiate between both versions when listing devices. Jan
signature.asc
Description: OpenPGP digital signature
