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

[Anthony Liguori]

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