From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH v5 0/9] toolstack-based approach to pvhvm guest kexec Date: Wed, 7 Jan 2015 10:41:23 +0000 Message-ID: <54AD0D53.6030209@citrix.com> References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com> <20150105124648.GF24360@zion.uk.xensource.com> <87r3v9pekz.fsf@vitty.brq.redhat.com> <20150107091057.GA12049@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y8o3N-0003nA-So for xen-devel@lists.xenproject.org; Wed, 07 Jan 2015 10:41:30 +0000 In-Reply-To: <20150107091057.GA12049@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering , Vitaly Kuznetsov Cc: Andrew Jones , Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Julien Grall , Ian Jackson , Tim Deegan , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org, Keir Fraser List-Id: xen-devel@lists.xenproject.org On 07/01/15 09:10, Olaf Hering wrote: > On Mon, Jan 05, Vitaly Kuznetsov wrote: > >> Wei Liu 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. > > 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