On Thu, 2023-02-16 at 11:49 +0100, Juan Quintela wrote: > David Woodhouse <dw...@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.
smime.p7s
Description: S/MIME cryptographic signature