[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip sup

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support
Date: Tue, 20 Dec 2011 09:34:41 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-12-20 04:10, Anthony Liguori wrote:
> On 12/19/2011 08:46 PM, Anthony Liguori wrote:
>> On 12/19/2011 07:19 PM, Jan Kiszka wrote:
>>> On 2011-12-20 02:08, Anthony Liguori wrote:
>> Here's how we solve this problem:
>> 1) In the short term, advertise both devices as having the same
>> VMstate name.
>> Since we don't register until the device is instantiated, this will
>> Just Work
>> and is easy.
>> 2) In the not so short term, we'll have Mike Roth's Visitor series
>> land in the
>> tree (Juan promised me it will be in his next pull request).
>> 3) Once we have the Visitor infrastructure in place, we can introduce
>> a self
>> describing migration format (that will also use QOM path names). With
>> a self
>> describing format, we can read all of the data from the wire into
>> memory without
>> consulting devices.
>> 4) We now have the ability to arbitrarily manipulate this tree in
>> memory. It's
>> just a matter or writing a small tree transformer that converts the
>> state to the APIC device state (by just renaming a level of the tree).
>> Heck, we
>> could even map fields if we needed to (although we should probably avoid
>> divergence if at all possible).
> The way this would is that something would register a migration "filter"
> when a userspace APIC was instantiated.  Maybe that's the device itself
> or maybe it's some centralized logic.  At any rate, since we have a
> self-describing format (and maybe it's just JSON), we can build a QObject.
> The filters would get called with the QObject before it was decoded and
> dispatched to devices.  It would look something like:
> static QDict *kvm_apic_to_userspace_apic(QDict *state, void *opaque)
> {
>    if (strcmp(qdict_get_str(state, "__type__"), "kvm-apic") {
>       QDict *userspace_apic = qdict_new();
>       const char *key;
>       qdict_foreach_key(&key, state) {
>           QObject *value = qdict_get(state, key);
>           qobject_incref(value);
>           qdict_put_obj(userspace_apic, key, value);
>       }
>       qdict_put_str(userspace_apic, "__type__", "apic");
>       return userspace_apic;
>    } else {
>       qobject_incref(state);
>       return state;
>    }
> }
> The same sort of filter function could also handle migration
> compatibility between virtio-blk-pci and a pair of virtio-blk/virtio-pci
> devices.  It would simply match on the __type__ of "virtio-blk-pci", and
> then split apart the state into an appropriate "virtio-pci" dictionary
> and a "virtio-blk" dictionary.
> This is just psuedo-code mind you.  We'll need to think carefully about
> how we recurse and apply these filters.  But it will be an extremely
> powerful mechanism that will let us solve most of these compatibility
> problems in an elegant way.

Another approach, which also solves an issue the above does not, go like

Use some device alias as name fore saving, and also accept this for
addressing the device in a running VM. The latter would allow for
/path/to/the/ioapic to always point you to the currently used IOAPIC
version, no matter if it is actually kvm-ioapic or [qemu-]ioapic. This
feature was requested by Avi back then. It doesn't map to existing
features directly, though.

In any case, I'm not going to touch a line of code until there is
consensus about the way to go.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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