This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: Possible regression in "x86-64: reduce range spanned

To: "Simon Horman" <horms@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Possible regression in "x86-64: reduce range spanned by 1:1 mapping and frame table indexes"
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 07 Dec 2009 11:06:44 +0000
Cc: Keir Fraser <keir.fraser@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 07 Dec 2009 03:07:08 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091207104824.GB31729@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091206235307.GA12909@xxxxxxxxxxxx> <4B1CE90702000078000240F3@xxxxxxxxxxxxxxxxxx> <20091207104824.GB31729@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Simon Horman <horms@xxxxxxxxxxxx> 07.12.09 11:48 >>>
>On Mon, Dec 07, 2009 at 10:37:43AM +0000, Jan Beulich wrote:
>> While I can't determine the exact source location corresponding to the
>> crash (without the disassembly of the function), the page table walk
>> suggests this is a read from to the M2P table, which imposes a couple
>> of questions: How can this be a non-quad-word aligned access? Is the
>> access, if it makes sense, guarded by an mfn_valid() check? Is the
>> memory address corresponding to the M2P slot (mfn 0x3c20001) in a
>> physical memory hole?
>Any tips on how I could investigate those questions?

For the first two, you'd have to connect register/stack values to
source variables (by analyzing the disassembly) to understand what
access it is that causes the issue, and where the values come from.
Or alternatively just add debugging printk()-s to the function in
question (but that could be a lot of output depending on how long the
guest survives). Or whatever else debugging technique you like...

For the third, all it takes is looking up the memory map in the hypervisor
(boot) log.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>