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:
0000000000000000
(XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi:
0000000000000000
(XEN) rbp: 0000000000000000 rsp: 0000000000000000 r8:
0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11:
0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14:
0000000000000000
(XEN) r15: 0000000000000000 cr0: 0000000000000000 cr3:
0000000000000000
(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?
-Xin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 15/8/06 1:34 pm, "Li, Xin B" <xin.b.li@intel.com> wrote:> + 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?Hi Xin, Try removing _PAGE_GLOBAL from line 117 of arch/x86/x86_64/mm.c. Should be a bit more correct. ;-) If that works let me know and I''ll apply the patch for you. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Try removing _PAGE_GLOBAL from line 117 of >arch/x86/x86_64/mm.c. Should be a >bit more correct. ;-) >Yes, it works fine for me, patch as your instructions: diff -r 7ff6020e4758 xen/arch/x86/x86_64/mm.c --- a/xen/arch/x86/x86_64/mm.c Thu Aug 03 15:02:34 2006 +0100 +++ b/xen/arch/x86/x86_64/mm.c Tue Aug 15 22:57:48 2006 +0800 @@ -113,8 +113,7 @@ void __init paging_init(void) PAGE_HYPERVISOR); memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0x55, 1UL << L2_PAGETABLE_SHIFT); - *l2_ro_mpt++ = l2e_from_page( - pg, _PAGE_GLOBAL|_PAGE_PSE|_PAGE_USER|_PAGE_PRESENT); + *l2_ro_mpt++ = l2e_from_page(pg, _PAGE_PSE|_PAGE_USER|_PAGE_PRESENT); BUG_ON(((unsigned long)l2_ro_mpt & ~PAGE_MASK) == 0); } BTW, seems the definition of RO_MPT_VIRT_START is misleading, should be RO_PMT_VIRT_START, also the comments around is incorrect. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/8/06 4:00 pm, "Li, Xin B" <xin.b.li@intel.com> wrote:> BTW, seems the definition of RO_MPT_VIRT_START is misleading, should be > RO_PMT_VIRT_START, also the comments around is incorrect.It *is* the read-only M2P for paravirtual guests. It''s just that we reuse that area of virtual address space for HVM guests. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> BTW, seems the definition of RO_MPT_VIRT_START is >misleading, should be >> RO_PMT_VIRT_START, also the comments around is incorrect. > >It *is* the read-only M2P for paravirtual guests. It''s just >that we reuse >that area of virtual address space for HVM guests. :-) >Got it, thanks a lot :-) -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel