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: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Possible regression in "x86-64: reduce range spanned by 1:1 mapping and frame table indexes"
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Mon, 7 Dec 2009 23:13:34 +1100
Cc: Keir Fraser <keir.fraser@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 07 Dec 2009 04:14:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B1CEFD40200007800024127@xxxxxxxxxxxxxxxxxx>
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> <4B1CEFD40200007800024127@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Dec 07, 2009 at 11:06:44AM +0000, Jan Beulich wrote:
> >>> 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...

Thanks, I was fearing something along those lines.

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

Ok, thats an easy one :-)

I'll poke some more tomorrow.

Xen-devel mailing list

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