[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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support
Date: Mon, 19 Dec 2011 21:10:00 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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);

          qdict_put_obj(userspace_apic, key, value);
      qdict_put_str(userspace_apic, "__type__", "apic");
      return userspace_apic;
   } else {
      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.


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.


Anthony Liguori


reply via email to

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