qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Woodhouse
Subject: Re: [RFC PATCH v11bis 00/26] Emulated XenStore and PV backend support
Date: Thu, 16 Feb 2023 14:51:01 +0100
User-agent: Evolution 3.44.4-0ubuntu1

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: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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