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 21:48:27 +1100
Cc: Keir Fraser <keir.fraser@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 07 Dec 2009 02:48:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B1CE90702000078000240F3@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Dec 07, 2009 at 10:37:43AM +0000, Jan Beulich wrote:
> >(XEN) ----[ Xen-3.5-unstable  x86_64  debug=y  Not tainted ]----
> >(XEN) CPU:    0
> >(XEN) RIP:    e008:[<ffff82c4801c0a72>] sh_remove_shadows+0x149/0x86a
> >(XEN) RFLAGS: 0000000000010286   CONTEXT: hypervisor
> >(XEN) rax: ffff8301140fa000   rbx: ffff82f601e10000   rcx: 0000000000000000
> >(XEN) rdx: ffff82c4801fb9e0   rsi: 00000000000f0800   rdi: ffff8301140fae1c
> >(XEN) rbp: ffff82c4802dfb68   rsp: ffff82c4802dfb38   r8:  00000000000f0800
> >(XEN) r9:  ffff8301186a8000   r10: ffff8300ddc08000   r11: 0000000000000000
> >(XEN) r12: ffff8300ddc08000   r13: 00000000000f0800   r14: ffff82c4802dff28
> >(XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000026f0
> >...
> >(XEN) Xen call trace:
> >(XEN)    [<ffff82c4801c0a72>] sh_remove_shadows+0x149/0x86a
> >(XEN)    [<ffff82c4801cbfff>] sh_page_fault__guest_2+0x184d/0x1bf3
> >(XEN)    [<ffff82c4801b2c1d>] vmx_vmexit_handler+0x717/0x1a68
> >(XEN)    
> >(XEN) Pagetable walk from ffff82f601e1000f:
> >(XEN)  L4[0x105] = 00000000decea027 5555555555555555
> >(XEN)  L3[0x1d8] = 000000011bffb063 5555555555555555
> >(XEN)  L2[0x00f] = 0000000000000000 ffffffffffffffff 
> >(XEN) 
> >(XEN) ****************************************
> >(XEN) Panic on CPU 0:
> >(XEN) [error_code=0000]
> >(XEN) Faulting linear address: ffff82f601e1000f
> >(XEN) ****************************************
> 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?

Xen-devel mailing list

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