>>> 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. Jan > 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@lists.xen.org http://lists.xen.org/xen-devel
