Re: [PATCH v5 0/9] toolstack-based approach to pvhvm guest kexec

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2015-01-07 at 10:41 +0000, David Vrabel wrote:
> On 07/01/15 09:10, Olaf Hering wrote:
> > On Mon, Jan 05, Vitaly Kuznetsov wrote:
> > 
> >> Wei Liu <wei.liu2@citrix.com> writes:
> >>
> >>> Olaf mentioned his concern about handling ballooned pages in
> >>> <20141211153029.GA1772@aepfle.de>. Is that point moot now?
> >>
> >> Well, the limitation is real and some guest-side handling will be
> >> required in case we want to support kexec with ballooning. But as David
> >> validly mentioned "It's the responsibility of the guest to ensure it
> >> either doesn't kexec when it is ballooned or that the kexec kernel can
> >> handle this". Not sure if we can (and need to) do anything hypevisor- or
> >> toolstack-side.
> > 
> > One approach would be to mark all pages as some sort of
> > populate-on-demand first. Then copy the existing assigned pages from
> > domA to domB and update the page type. The remaining pages are likely
> > ballooned. Once the guest tries to access them this should give the
> > hypervisor and/or toolstack a chance to assign a real RAM page to them.
> > 
> > I mean, if a host-assisted approach for kexec is implemented then this
> > approach must also cover ballooning.
> 
> It is not possible for the hypervisor or toolstack to do what you want
> because there may not be enough free memory to repopulate the new domain.
> 
> The guest can handle this by:
> 
> 1. Not ballooning (this is common in cloud environments).
> 2. Reducing the balloon prior to kexec.
> 3. Running the kexec'd image in a reserved chunk of memory (the crash
> kernel case).
> 4. Providing balloon information to the kexec'd image.

Is #4 not just some sort of special case of "provide a memory map to the
kexec'd kernel"? I suppose it's significantly more fine grained and
therefore doesn't fit into the usual data structures which kexec might
already support throwing over the fence.

(Olaf's suggesting to use PoD in a different subthread was interesting
too).

> None of these require any additional hypervisor or toolstack support and
> 1-3 are trivial for a guest to implement.
> 
> David