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

[Anthony Liguori]

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