[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infra

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse
Date: Tue, 20 Dec 2011 15:55:40 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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:


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

Yes, they just need to read the 'type' property. The distinguishing property would be:

/cpus/cpu0/apic.type = 'apic'


/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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]