Re: [Xen-devel] [PATCH] xen/x86: domain: Free all the pages associated to struct domain

["Woodhouse, David" <dwmw@xxxxxxxxxxxx>]

On Wed, 2020-01-22 at 13:15 +0000, Andrew Cooper wrote:
> > > I'd much rather see the original patch reverted.  The current size of
> > > struct domain with lockprofile enabled is 3200 bytes.
> > 
> > Let me have a look first to see when/why struct domain is less than 4K
> > with lockprofile.
> 
> In the intervening time, Juergen has totally rewritten lock profiling,
> and the virtual timer infrastructure has been taken out-of-line.
> 
> Its probably the latter which is the dominating factor.

OK, so if we revert 8916fcf4577 is it reasonable for me to then assume
that 'struct domain' will always fit within a page, and declare that
live update shall not work to a Xen where that isn't true?

I have a nasty trick in mind...

During live update, we need to do a pass over the live update data in
early boot in order to work out which pages to reserve. That part has
to be done early, while the boot allocator is active. It works by
setting the PGC_allocated bit in the page_info of the reserved pages,
so that init_heap_pages() knows not to include them. I've posted that
part already.

Also during live update, we need to consume the actual domain state
that was passed over from the previous Xen, and fill in the owner (and
refcount etc.) in the same page_info structures, before those pages are
in a truly consistent state.

Right now, we need the latter to happen *after* the boot allocator is
done and we're able to allocate from the heap... because we need to be
able to allocate the domain structures, and we don't want to ensure
that there's enough space in the LU reserved bootmem for that many
domain structures.

Hence the nasty trick: What if we allocate the new struct domain on
*top* of the old one, since we happen to know that page *wasn't* used
by the previous Xen for anything that needs to be preserved. The
structure itself isn't an ABI and never can be, and it will have to be
repopulated from the live migration data, of course — but if we can at
least make the assumption that it'll *fit*, then perhaps we can manage
to do both of the above with only one pass over all the domain pages.

This will have a direct effect on the customer-observed pause time for
a live update. So it's kind of icky, but also *very* tempting...



Amazon Development Centre (London) Ltd. Registered in England and Wales with 
registration number 04543232 with its registered office at 1 Principal Place, 
Worship Street, London EC2A 2FA, United Kingdom.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel