From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
Date: Tue, 13 Jan 2015 17:45:23 +0100
Message-ID: <874mrud3z0.fsf@vitty.brq.redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-5-git-send-email-vkuznets@redhat.com>
	<1421157237.19103.61.camel@citrix.com>
	<1421157237.19103.61.camel@citrix.com>
	<87oaq2d59p.fsf@vitty.brq.redhat.com>
	<54B554CD02000078000547EB@mail.emea.novell.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.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1YB4b7-0004t7-56
	for xen-devel@lists.xenproject.org; Tue, 13 Jan 2015 16:45:41 +0000
In-Reply-To: <54B554CD02000078000547EB@mail.emea.novell.com> (Jan Beulich's
	message of "Tue, 13 Jan 2015 16:24:29 +0000")
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: Jan Beulich <JBeulich@suse.com>
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien.grall@linaro.org>, Ian Jackson <ian.jackson@eu.citrix.com>, Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 13.01.15 at 17:17, <vkuznets@redhat.com> wrote:
>> Ian Campbell <Ian.Campbell@citrix.com> writes:
>>> 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.
>> 
>> Something like that (but not exactly) was in my RFC/WIPv2 series:
>> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03624.html 
>> 
>> The drawback of such approach is the necessity of copying all mapped
>> more than once pages (granted pages, qemu-mapped pages, ...) or at least
>> providing blank pages instead of them. 
>
> Why would that be necessary only in that alternative model? What
> gets done with pages used by other than _just_ the dying domain
> shouldn't depend on how the MFN/GFN relationship gets determined.

The difference comes from the fact that in the current model (when we
have a hook in free_domheap_pages()) we don't care who frees the
particular page first - our dying domain or e.g. a backend from dom0,
eventually all pages are freed. In the alternative model (one hypercall
reassigning all pages) we need to go through all domheap pages before
we start domain cleanup (unless we modify the domain cleanup path) or
some or all pages may got lost.

-- 
  Vitaly