Re: kexec -e in PVHVM guests (and in PV).

[Olaf Hering <olaf@aepfle.de>]

On Mon, Jun 30, Konrad Rzeszutek Wilk wrote:

>  4). Balloon memory. I am not really sure how to deal with that. The
>      guest might have ballooned out tons of memory but the new kernel
>      won't know about it until the xen/balloon driver kicks in and
>      figures this out based on XenStore. Then it will try to balloon
>      out.. and depending on its luck - balloon out memory that was
>      already ballooned out, or not.  Also during the bootup of
>      the 'kexec -e' kernel it might touch pages that had been
>      ballooned out - and try to use them!

The solution so far is to balloon up until all ballooned pages are
backed by RAM.

Long time ago I had the idea to give the new kernel large ranges of
contigous memory. To do that I had some buggy code in the kexec code
path which claims all free pfns. Then it walks through the list of
ballooned pfns and flips the state of the pfn, a ballooned pfn gets
unballooned and a free page becomes ballooned. The result is that there
are eventually large contigous ranges for the startup code of the new
kernel. Later the mm init code of the new kernel walks the whole pfn
range and creates a list of already ballooned pfns for the balloon
driver and the mm itself.

This catch was, and likely still is: what does the kexec startup code
expect as memory layout? What ranges of memory does it need to touch? At
the time of kexec -l the memory layout differs from the memory layout at
kexec -e. Once this is solved something like the page flipping above can
be implemented.

Olaf