WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Simon Horman" <horms@xxxxxxxxxxxx>
Subject: [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 10:37:43 +0000
Cc: Keir Fraser <keir.fraser@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 07 Dec 2009 02:38:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091206235307.GA12909@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>(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) FATAL PAGE FAULT
>(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?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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