[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.
smime.p7s
Description: S/MIME cryptographic signature
- [RFC PATCH v11bis 09/26] hw/xen: Add evtchn operations to allow redirection to internal emulation, (continued)
- [RFC PATCH v11bis 09/26] hw/xen: Add evtchn operations to allow redirection to internal emulation, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 08/26] hw/xen: Create initial XenStore nodes, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 01/26] hw/xen: Add xenstore wire implementation and implementation stubs, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 13/26] hw/xen: Add xenstore operations to allow redirection to internal emulation, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 16/26] hw/xen: Rename xen_common.h to xen_native.h, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 20/26] hw/xen: Hook up emulated implementation for event channel operations, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 12/26] hw/xen: Add foreignmem operations to allow redirection to internal emulation, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 11/26] hw/xen: Pass grant ref to gnttab unmap operation, David Woodhouse, 2023/02/16
- [RFC PATCH v11bis 07/26] hw/xen: Implement core serialize/deserialize methods for xenstore_impl, David Woodhouse, 2023/02/16
- Re: [RFC PATCH v11bis 00/26] Emulated XenStore and PV backend support, Juan Quintela, 2023/02/16
- Re: [RFC PATCH v11bis 00/26] Emulated XenStore and PV backend support,
David Woodhouse <=