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] hypervisor crash look familiar?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] hypervisor crash look familiar?
From: Joe Bonasera <joe.bonasera@xxxxxxx>
Date: Fri, 21 Sep 2007 10:23:24 -0700
Delivery-date: Fri, 21 Sep 2007 10:24:10 -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
User-agent: Thunderbird (X11/20070723)

We're getting a very difficult to reproduce hypervisor
crash that happens 3.0.4 based bits running PAE 32 bit.
I'm wondering if this looks familiar to anyone and hoping
it's been fixed in later releases. It seems to happen

Here's the crash information from one of the occurences:

(XEN) extable.c:77: Pre-exception: ff140fcc -> 00000000
(XEN) ----[ Xen-3.0.4-1-sun  x86_32p  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) EIP:    e008:[<ff140fcc>] __spurious_page_fault+0x95/0x407
(XEN) EFLAGS: 00010006   CONTEXT: hypervisor
(XEN) eax: 00000000   ebx: 0004b386   ecx: 00000003   edx: 00000000
(XEN) esi: 4b386000   edi: fedab000   ebp: ff1dbdbc   esp: ff1dbd24
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 4b386000   cr2: fedab018
(XEN) ds: e010   es: e010   fs: 0000   gs: 01b1   ss: e010   cs: e008
(XEN) Xen stack trace from esp=ff1dbd24:
(XEN)    0004b386 ff1dbf20 000001ad ff133317 f6ea8078 cd400228 00000002
(XEN)    00000000 00000001 fedab000 00000004 ff12fa06 fedad000 ff228100
(XEN)    00000000 00000001 ff228100 f6edc020 ff1dbdcc ff12f300 f6edc020
(XEN)    f6edc030 f6edc030 00000003 80000000 f6edc020 00000000 00000003
(XEN)    f6edc020 000000fd 01228100 80000001 ff228100 00048b62 ff228500
(XEN)    00000282 feda7fcc feda7fcc ff1dbddc ff14135a feda7fcc ff1dbe08
(XEN)    ff228100 ff1dbe08 feda7fcc ff1dbe08 ff1dbdfc ff14171a feda7fcc
(XEN)    ff1dbe08 ff1dbdfc ff13c675 ff234100 ff1dffcc 00e241e3 ff17dd02
(XEN)    ff1dbe08 00000000 0000000d 000002a0 ff1dffcc feda7fcc ff1dbe6c
(XEN)    00000000 000e0002 ff12fbd1 0000e008 00010212 00047005 00000000
(XEN)    ff1dbe6c ff12f8bd f6ed1130 fde69c50 80000000 00000000 feda7000
(XEN)    f6ea8078 fedab000 ff1dbfb4 00000000 00000000 ff1dbebc ff1325c7
(XEN)    fedab000 00000002 ff1dbe9c ff13c74e 00000002 000000fd ff228100
(XEN)    ff1438cc cd75ea7c 00000000 ff1dbfb4 ff228100 48b03001 00000000
(XEN)    f6f0d490 78000002 f6f0d490 0004b386 ff1dbf8c ff135204 fedab000
(XEN)    00000000 00000000 0004b386 48000001 ff1dbf58 ff13a0d3 ff1dbf20
(XEN)    ff1a4a28 80000002 ff1dbf8c ff228100 f73f94d8 a0000000 ff1dbf18
(XEN)    ff1dbfb4 ff228100 ff1b5540 ff1b5540 ff1b5540 f6ed0850 ff1dbfb4
(XEN)    ff228100 ff234100 00000000 00000000 00000000 fedab000 ff228100
(XEN)    00000000 00000000 ff234100 00000000 00000000 00000000 00000001
(XEN) Xen call trace:
(XEN)    [<ff140fcc>] __spurious_page_fault+0x95/0x407
(XEN)    [<ff14135a>] spurious_page_fault+0x1c/0x24
(XEN)    [<ff14171a>] do_page_fault+0x1b5/0x21d
(XEN)    [<ff17dd02>] handle_exception+0x62/0x92
(XEN)    [<ff12fbd1>] create_pae_xen_mappings+0x142/0x290
(XEN)    [<ff1325c7>] mod_l3_entry+0x813/0x878
(XEN)    [<ff135204>] do_mmu_update+0x582/0xbe3
(XEN)    [<ff17d9f5>] hypercall+0x95/0xb5
(XEN) Faulting linear address: fedab018
(XEN) Pagetable walk from fedab018:

From examining the code, the
create_pae_xen_mappings()+142 location corresponds to the
first store instruction of the l2write() call
in the first loop in this bit of create_pae_xen_mappings()

    /* Xen private mappings. */
    pl2e = map_domain_page(l3e_get_pfn(l3e3));
           L2_PAGETABLE_XEN_SLOTS * sizeof(l2_pgentry_t));
    for ( i = 0; i < PDPT_L2_ENTRIES; i++ )
        l2e = l2e_from_page(
            virt_to_page(page_get_owner(page)->arch.mm_perdomain_pt) + i,
        l2e_write(&pl2e[l2_table_offset(PERDOMAIN_VIRT_START) + i], l2e);
    for ( i = 0; i < (LINEARPT_MBYTES >> (L2_PAGETABLE_SHIFT - 20)); i++ )
        l2e = l2e_empty();
        if ( l3e_get_flags(pl3e[i]) & _PAGE_PRESENT )
            l2e = l2e_from_pfn(l3e_get_pfn(pl3e[i]), __PAGE_HYPERVISOR);
        l2e_write(&pl2e[l2_table_offset(LINEAR_PT_VIRT_START) + i], l2e);

That l2e_write() essentially expands to:

    u32 *__ptep_words = (u32 *)(ptep);                        \
    __ptep_words[0] = 0;                                      \
    wmb();                                                    \
    __ptep_words[1] = (pte) >> 32;                            \
    wmb();                                                    \
    __ptep_words[0] = (pte) >>  0;                            \

and it's the mov instruction that does __ptep_words[0] = 0;
which pagefaults.

Xen-devel mailing list

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