On 2011-12-20 22:55, Anthony Liguori wrote: > 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. 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. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
