From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC Patch v3 01/18] copy the correct page to memory
Date: Mon, 8 Sep 2014 12:58:02 +0100
Message-ID: <540D99CA.1000704@citrix.com>
References: <1409908261-18682-1-git-send-email-wency@cn.fujitsu.com>	
	<1409908261-18682-2-git-send-email-wency@cn.fujitsu.com>
	<1410175661.10156.191.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1410175661.10156.191.camel@kazak.uk.xensource.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: Ian Campbell <Ian.Campbell@citrix.com>, Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>, xen devel <xen-devel@lists.xen.org>, Hong Tao <bobby.hong@huawei.com>, Yang Hongyang <yanghy@cn.fujitsu.com>
List-Id: xen-devel@lists.xenproject.org

On 08/09/14 12:27, Ian Campbell wrote:
> On Fri, 2014-09-05 at 17:10 +0800, Wen Congyang wrote:
>> From: Hong Tao <bobby.hong@huawei.com>
>>
>> apply_batch() only handles MAX_BATCH_SIZE pages at one time. If
>> there is some bogus/unmapped/allocate-only/broken page, we will
>> skip it. So when we call apply_batch() again, the first page's
>> index is curbatch - invalid_pages. invalid_pages stores the number
>> of bogus/unmapped/allocate-only/broken pages we have found.
>>
>> In many cases, invalid_pages is 0, so we don't catch this error.
>>
>> Signed-off-by: Hong Tao <bobby.hong@huawei.com>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Hopefully all of this stuff will soon be replaced by migration v2 but we
> may as well apply this fix in the meantime. CCing Andy C on the unlikely
> chance that he carried this misbehaviour over into v2.

I rewrote all of this from scratch.

Amongst other things, the v2 code doesn't batch explicitly batch on the
restoring side.  It will deal with an individual PAGE_DATA record at
once, which will generally contain 1024 pages of data, but will not
cache some parts of this to batch better with the following PAGE_DATA
record, which appears to be the source of this bug.

As for deletion.  I am planning to delete it as part of the v2 series,
although that might get complicated if remusv2 is not ready by that point.

~Andrew