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


[Xen-devel] A random bug introduced in C/S 10918

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] A random bug introduced in C/S 10918
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Tue, 15 Aug 2006 20:34:14 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 15 Aug 2006 05:35:04 -0700
Envelope-to: www-data@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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbAZx4ugltCVnl8QUaZNyAwR4A5Dw==
Thread-topic: A random bug introduced in C/S 10918
Hi Keir,
After C/S 10918, we often encountered a bug when creating HVM guests:
(XEN) Can not find E820 memory map page for HVM domain.
(XEN) domain_crash_sync called from hvm.c:98
(XEN) Domain 1 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-3.0-unstable    Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0010:[<0000000000100000>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx:
(XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi:
(XEN) rbp: 0000000000000000   rsp: 0000000000000000   r8:
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11:
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14:
(XEN) r15: 0000000000000000   cr0: 0000000000000000   cr3:
(XEN) ds: 0008   es: 0008   fs: 0008   gs: 0008   ss: 0008   cs: 0010

But it doesn't always happen, and more investigation shows that
get_mfn_from_gpfn sometimes works fine while sometimes returns invalid
mfn.  Actually it's caused by the removing of "local_flush_tlb_pge()" in
e820_foreach(), and the following patch fixes it.

diff -r 7ff6020e4758 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c    Thu Aug 03 15:02:34 2006 +0100
+++ b/xen/arch/x86/hvm/hvm.c    Tue Aug 15 18:07:15 2006 +0800
@@ -91,6 +91,8 @@ static void e820_foreach(struct domain *
     unsigned char *p;
     unsigned long mfn;
+    local_flush_tlb_pge();
     mfn = gmfn_to_mfn(d, E820_MAP_PAGE >> PAGE_SHIFT);
     if ( mfn == INVALID_MFN )

I don't think this is a clean fix, but how can this happen? Seems p2m
table TLB entries sometimes are not flushed when loading a new cr3
value.  Can you help to take a look?


Xen-devel mailing list

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