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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
