From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
Date: Tue, 13 Jan 2015 13:53:57 +0000
Message-ID: <1421157237.19103.61.camel@citrix.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-5-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1YB1v2-0005La-Io
	for xen-devel@lists.xenproject.org; Tue, 13 Jan 2015 13:54:04 +0000
In-Reply-To: <1418305541-5135-5-git-send-email-vkuznets@redhat.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>, Keir Fraser <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

On Thu, 2014-12-11 at 14:45 +0100, Vitaly Kuznetsov wrote:
> +            gmfn = mfn_to_gmfn(d, mfn);

(I haven't thought about it super hard, but I'm taking it as given that
this approach to kexec is going to be needed for ARM too, since that
seems likely)

mfn_to_gmfn is going to be a bit pricey on ARM, we don't have an m2p to
refer to, I'm not sure what we would do instead, walking the p2m looking
for mfns surely won't be a good idea!

An alternative approach to this might be to walk the guest p2m (with
appropriate continuations) and move each domheap page (this would also
help us preserve super page mappings). It would also have the advantage
of not needing additional stages in the destroy path and state in struct
domain etc, since all the action would be constrained to the one
hypercall.

x86 folks, would that work for your p2m too?

Ian.