Re: [RFC PATCH v11bis 00/26] Emulated XenStore and PV backend support

[Juan Quintela <quintela@redhat.com>]

David Woodhouse <dwmw2@infradead.org> wrote:
> The non-RFC patch submisson¹ is just the basic platform support for Xen
> on KVM. This RFC series is phase 2, adding an internal XenStore and
> hooking up the PV back end drivers to that and the emulated grant tables
> and event channels.
>
> With this, we can boot a Xen guest with PV disk, under KVM. Full support
> for migration isn't there yet because it's actually missing in the PV
> back end drivers in the first place (perhaps because upstream Xen doesn't
> yet have guest transparent live migration support anyway). I'm assuming
> that when the first round is merged and we drop the [RFC] from this set,
> that won't be a showstopper for now?
>
> I'd be particularly interested in opinions on the way I implemented
> serialization for the XenStore, by creating a GByteArray and then dumping
> it with VMSTATE_VARRAY_UINT32_ALLOC().

And I was wondering why I was CC'd in the whole series O:-)

How big is the xenstore?
I mean typical size and maximun size.

If it is suficientely small (i.e. in the single unit megabytes), you can
send it as a normal device at the end of migration.

If it is bigger, I think that you are going to have to enter Migration
iteration stage, and have some kind of dirty bitmap to know what entries
are on the target and what not.

As examples, we are going to discuss how to migrate Vhost-user-fs in the
near future, and as far as I know that is something similar to the
Xenstore (from 10000 feet view, both are a (key, value) store, no?).

We are having starting other discussions about how to migrate vfio and
(not yet started) vhost/vpda devices, so you can get some "inspiration"
from there if you are going the "opaque" route.

Later, Juan.