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 11:49:05 +0100 Message-ID: <87y4pekgri.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> 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 1Y8oB6-0004NX-KT for xen-devel@lists.xenproject.org; Wed, 07 Jan 2015 10:49:28 +0000 In-Reply-To: <20150107091057.GA12049@aepfle.de> (Olaf Hering's message of "Wed, 7 Jan 2015 10:10:57 +0100") 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 Cc: Andrew Jones , Julien Grall , Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Tim Deegan , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org, Keir Fraser List-Id: xen-devel@lists.xenproject.org Olaf Hering writes: > 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. The thing is .. we don't have these pages when kexec is being performed, they are already ballooned out and the hypervisor doesn't have the knowledge of which GFNs should be re-populated. I think it is possible to keep track of all pages the guest balloons out for this purpose, but .. > > I mean, if a host-assisted approach for kexec is implemented then this > approach must also cover ballooning. I don't see why solving the issue hypervisor-side is a must. When the guest performs kdump we don't care about the ballooning as we have a separate memory area which is supposed to have no ballooned out pages. When we do kexec nothing stops us from asking balloon driver to bring everything back, it is fine to perform non-trivial work before kexec (e.g. we shutdown all the devices). But, as I said, I'll try playing with ballooning to make these thoughts not purely theoretical. -- Vitaly