From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH v5 0/9] toolstack-based approach to pvhvm guest kexec Date: Wed, 07 Jan 2015 12:59:01 +0100 Message-ID: <87tx02kdiy.fsf@vitty.brq.redhat.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> <54AD0D53.6030209@citrix.com> <54AD1E7102000078000523BA@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y8pGg-0000jg-0y for xen-devel@lists.xenproject.org; Wed, 07 Jan 2015 11:59:18 +0000 In-Reply-To: <54AD1E7102000078000523BA@mail.emea.novell.com> (Jan Beulich's message of "Wed, 07 Jan 2015 10:54:25 +0000") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Olaf Hering , Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Julien Grall , Ian Jackson , Andrew Jones , TimDeegan , David Vrabel , xen-devel@lists.xenproject.org, Keir Fraser List-Id: xen-devel@lists.xenproject.org "Jan Beulich" writes: >>>> On 07.01.15 at 11:41, wrote: >> 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. > > 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