From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: Problem about dump-core
Date: Wed, 17 Sep 2014 08:50:38 +0800
Message-ID: <5418DADE.60006@cn.fujitsu.com>
References: <5417A1D6.1010606@cn.fujitsu.com>	
	<5417E58C.3030906@cn.fujitsu.com>
	<1410885518.23505.11.camel@citrix.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: <1410885518.23505.11.camel@citrix.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>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, xen devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 09/17/2014 12:38 AM, Ian Campbell wrote:
> On Tue, 2014-09-16 at 15:23 +0800, Wen Congyang wrote:
>> On 09/16/2014 10:35 AM, Wen Congyang wrote:
>>> Hi, everyone:
>>>
>>> The command 'xl dump-core' will fail after migration. The guest is HVM guest(without pv driver).
>>> I use the newest staging branch to test. Both source and dest dom0 use the same kernel.
>>
>> The kernel version is 3.2, and it only supports IOCTL_PRIVCMD_MMAPBATCH.
>>
>> After more investigation, the reason is that the mfn is ~0UL, and xc_map_foreign_range()
>> doesn't return NULL on dest host.
>>
>> This patch can fix this problem:
>>
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Date: Tue, 16 Sep 2014 14:56:03 +0800
>> Subject: [PATCH] check if mfn is valid before checking if PRIVCMD_MMAPBATCH_MFN_ERROR is set
>>
>> If mfn is invalid, ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, ..) also returns 0,
>> and we set mfn to mfn | PRIVCMD_MMAPBATCH_MFN_ERROR. But if mfn is ~0UL,
>> pfn[i] ^ arr[i] returns 0, and we cannot find this error. So we should
>> check if mfn is valid first before testing pfn[i] ^ arr[i].
> 
> I don't think we can reliably distinguish between a large MFN and an
> error with this approach, can we?
> 
> I suspect it would be better to perform a check before making the
> hypercall that the 4 (?) error bits are not set in the input.

Yes, we can check it more earlier. If the 4 error bits are set, is it a valid
mfn?

Thanks
Wen Congyang

> 
> Ian.
> 
> .
>