[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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse
Date: Tue, 20 Dec 2011 23:20:31 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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