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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]

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
>> KVM-APIC
>> 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
this:

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]