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

[Vitaly Kuznetsov <vkuznets@redhat.com>]

Olaf Hering <olaf@aepfle.de> writes:

> 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.

The thing is .. we don't have these pages when kexec is being performed,
they are already ballooned out and the hypervisor doesn't have the
knowledge of which GFNs should be re-populated. I think it is possible
to keep track of all pages the guest balloons out for this purpose, but 
..

>
> I mean, if a host-assisted approach for kexec is implemented then this
> approach must also cover ballooning.

I don't see why solving the issue hypervisor-side is a must. When the
guest performs kdump we don't care about the ballooning as we have a
separate memory area which is supposed to have no ballooned out
pages. When we do kexec nothing stops us from asking balloon driver to
bring everything back, it is fine to perform non-trivial work before
kexec (e.g. we shutdown all the devices).

But, as I said, I'll try playing with ballooning to make these thoughts
not purely theoretical.

-- 
  Vitaly