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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 07/01/15 09:10, Olaf Hering wrote:
> On Mon, Jan 05, Vitaly Kuznetsov wrote:
> 
>> Wei Liu <wei.liu2@xxxxxxxxxx> writes:
>>
>>> Olaf mentioned his concern about handling ballooned pages in
>>> <20141211153029.GA1772@xxxxxxxxx>. 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.

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

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel