On Wed, 2015-01-07 at 10:41 +0000, David Vrabel 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. > 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.
Is #4 not just some sort of special case of "provide a memory map to the kexec'd kernel"? I suppose it's significantly more fine grained and therefore doesn't fit into the usual data structures which kexec might already support throwing over the fence. (Olaf's suggesting to use PoD in a different subthread was interesting too). > 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
