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.
Regards,
Anthony Liguori
5) We can now hand this manipulated tree to an input Visitor and the devices
will read it in as if it came from the same device.
This is the level of flexibility we need to support migration compatibility
moving forward. We're actually not that far from it either. We'll definitely
have it in place before we have a new migration protocol.
Regards,
Anthony Liguori
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
