David Woodhouse <dw...@infradead.org> wrote: > --=-jDk4SYxkcOAZoZa6DCVr > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Thu, 2023-02-16 at 11:49 +0100, Juan Quintela wrote: >> David Woodhouse <dw...@infradead.org> wrote: >> > The non-RFC patch submisson=C2=B9 is just the basic platform support fo= > r 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 table= > s >> > and event channels. >> >=20 >> > With this, we can boot a Xen guest with PV disk, under KVM. Full suppor= > t >> > 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? >> >=20 >> > I'd be particularly interested in opinions on the way I implemented >> > serialization for the XenStore, by creating a GByteArray and then dumpi= > ng >> > it with VMSTATE_VARRAY_UINT32_ALLOC(). >>=20 >> And I was wondering why I was CC'd in the whole series O:-) >>=20 > > 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. >>=20 > > 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. >>=20 > > 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. >>=20 > > We have COW and transactions; that isn't an impossibility; I think we > can avoid that complexity though.
It is relatively small. I will go with migrating at the end of migration for now. Later we can measure if we need to improve performance there. Later, Juan.