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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On Thu, 2023-02-16 at 11:49 +0100, Juan Quintela wrote:
> 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:-)
> 

Indeed, Philippe M-D added you to Cc when discussing migrations on the
first RFC submission back in December, and you've been included ever
since.


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

Booting a simple instance with a single disk:

$ scripts/analyze-migration.py -f foo | grep impl_state_size
        "impl_state_size": "0x00000634",

Theoretical maximum is about 1000 nodes @2KiB, so around 2MiB.

> 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.
> 

Right now it's part of the xen_xenstore device. Most of that is fairly
simple and it's just the impl_state that's slightly different.


> 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.
> 

We have COW and transactions; that isn't an impossibility; I think we
can avoid that complexity though.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]