From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Problem about dump-core Date: Tue, 16 Sep 2014 17:38:38 +0100 Message-ID: <1410885518.23505.11.camel@citrix.com> References: <5417A1D6.1010606@cn.fujitsu.com> <5417E58C.3030906@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5417E58C.3030906@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wen Congyang Cc: Andrew Cooper , Ian Jackson , xen devel List-Id: xen-devel@lists.xenproject.org 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 > 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. Ian.