"Jan Beulich" <jbeul...@suse.com> writes: >>>> On 07.01.15 at 11:41, <david.vra...@citrix.com> wrote: >> On 07/01/15 09:10, Olaf Hering wrote: >>> On Mon, Jan 05, Vitaly Kuznetsov wrote: >>> >>>> Wei Liu <wei.l...@citrix.com> writes: >>>> >>>>> Olaf mentioned his concern about handling ballooned pages in >>>>> <20141211153029.ga1...@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. > > Which may fail because again there may not be enough memory to > claim back from the hypervisor. >
Yes, but it may be better to cancel kexec at this point. -- Vitaly _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
