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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/20/2011 04:20 PM, Jan Kiszka wrote:
> On 2011-12-20 22:55, Anthony Liguori wrote:
>> The components of the path are the *property* names of the parent
>> device.  In the case of the local APIC, you would have something like:
>>
>> /cpus/cpu0/apic
>> /cpus/cpu1/apic
>>
>> Which would be links on the composition tree.  The name wouldn't change
>> even if the type of this object changed.
>
> Perfect! That was what I forgot about and what makes it possible to
> return to the original two-device model.
>
>> You'll probably have a flag or
>> something in the cpu object that lets you determine whether the child is
>> created as a kvm-apic or just a normal apic.
>
> I rather hope you will be able to ask the device for its type instead
> replicating that information.

Yes, but that's not what I was getting at.

I think you are currently planning on enabling/disabling the in-kernel apic 
through a machine option?

Where I'd like to get to is that the CPUs are modeled as devices and whether the 
APIC is in-kernel or not is a property of the CPU (just like any other CPU flag).

For something like the i8254, since that's a child of the PIIX3, it would be a 
property of the PIIX3 which it would use to create the appropriate i8254 type.

You could also have the CPU and/or i8254 have a link<> which would allow a user 
to explicitly instantiate the appropriate device but I think that makes it 
harder to use than it should be.

By making it a property of the composition parent, you let the parent make the 
best choice to start with and then a user has the ability to override it if it 
sees fit to.

Regards,

Anthony Liguori

> Jan
>