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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux