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:
signature.asc
Description: OpenPGP digital signature
