|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse |
Date: | Tue, 20 Dec 2011 17:41:56 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |