On 12/20/2011 03:45 PM, Jan Kiszka wrote:
On 2011-12-20 22:38, Anthony Liguori wrote:
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).
There is no such thing as "qtree paths". Today, devices have ids or are
anonymous. The apic is currently an anonymous device and there's no way to
address it until we complete the PC composition tree. I have patches for this,
but that won't land until after series 4.
Starting right now, we have a standard path mechanism. This path will either
follow the composition tree or potentially an arbitrary path through the link graph.
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. 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. But that would only affect the 'type' flag.
The request was that /qtree/path/to/apic should not change if you enable
KVM in-kernel acceleration in the very same qemu release.
The type names of the devices are orthogonal to the path names.
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.
Yes, they just need to read the 'type' property. The distinguishing property
would be:
/cpus/cpu0/apic.type = 'apic'
vs.
/cpus/cpu0/apic.type = 'kvm-apic'
But otherwise, it would look the same.
Again, if you implement qdev based inheritance as I described in my previous
note, this will all Just Work. We have everything we need in the tree to model
this.
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
