From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCH v3 0/1] Introduce VCPUOP_reset_vcpu_info
Date: Fri, 22 Aug 2014 13:41:38 +0100
Message-ID: <53F73A82.3060702@citrix.com>
References: <1408442683-12125-1-git-send-email-vkuznets@redhat.com>
	<53F39EA8.5020602@cantab.net>
	<20140820133742.GI3120@laptop.dumpdata.com>
	<20140820215730.GB6411@laptop.dumpdata.com>
	<87mwayku4n.fsf@vitty.brq.redhat.com>
	<20140822022741.GG20329@laptop.dumpdata.com>
	<53F72490020000780002C91E@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.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XKoAQ-0005mv-CO
	for xen-devel@lists.xenproject.org; Fri, 22 Aug 2014 12:42:06 +0000
In-Reply-To: <53F72490020000780002C91E@mail.emea.novell.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: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: David Vrabel <dvrabel@cantab.net>, xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>
List-Id: xen-devel@lists.xenproject.org

On 22/08/14 10:08, Jan Beulich wrote:
>>>> On 22.08.14 at 04:27, <konrad.wilk@oracle.com> wrote:
>> On Thu, Aug 21, 2014 at 12:35:36PM +0200, Vitaly Kuznetsov wrote:
>>> Recreating domain and copying all memory should work but we'll require
>>> host to have free memory, this can be an issue for large guests. If we
>>> try implementing 'reassigning' of memory without making a copy that can
>>> lead to same issues we have now: mounted grants, shared info,...
>>
>> That is a good point. Especially with 512GB guests. David, Jan, thoughts?
> 
> No, the idea was really to re-use the memory rather than copy it.
> Why would active grants or the use of shared info be a problem
> (and particularly one worse than with the vCPU-info-reset
> approach)?

An initial prototype that copies the memory may be a useful first step
as this will be straight-forward (most of the bits can be borrowed from
save/restore).

If the domain has mapped granted pages then the new domain should not
retain the mappings (otherwise you will end up with a domain having
mappings of a grant that does not agree with the domain in the granter's
grant table).

If the domain has granted pages, it should probably copy those pages and
not reuse then (because updating the map tracking info is probably
non-trivial).

David