[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages
On 05/23/2017 09:17 AM, Jan Beulich wrote: >>>> On 23.05.17 at 15:00, <boris.ostrovsky@xxxxxxxxxx> wrote: >> (d1) Testing HVM environment: >> (XEN) d1v0 Triple fault - invoking HVM shutdown action 1 >> (XEN) *** Dumping Dom1 vcpu#0 state: *** >> (XEN) ----[ Xen-4.9-rc x86_64 debug=y Tainted: C ]---- >> (XEN) CPU: 11 >> (XEN) RIP: 0018:[<000000000010815c>] >> (XEN) RFLAGS: 0000000000000086 CONTEXT: hvm guest (d1v0) >> (XEN) rax: 0000000080000011 rbx: 000000000017c000 rcx: 0000000000003000 >> (XEN) rdx: 00000000ffefffff rsi: 0000000000000000 rdi: 0000000000000000 >> (XEN) rbp: 0000000000136478 rsp: 0000000000136478 r8: 0000000000000000 >> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >> (XEN) r15: 0000000000000000 cr0: 0000000080000011 cr4: 0000000000000000 >> (XEN) cr3: 0000000000800000 cr2: 000000000010815c >> (XEN) ds: 0020 es: 0020 fs: 0020 gs: 0020 ss: 0020 cs: 0018 >> >> >> 0x10815c is tools/firmware/hvmloader/tests.c:start_paging(), the 'jmp' >> after we enable paging (load cr0 with bit 31 set). > Odd. Suggests page tables are completely screwed. > >> root@ovs101> xl create -c ~/virt/pvh.conf >> Parsing config from /root/virt/pvh.conf >> libxl: notice: libxl_numa.c:518:libxl__get_numa_candidate: NUMA >> placement failed, performance might be affected >> S3 disabled >> S4 disabled >> CONV disabled >> xc: error: panic: xc_dom_boot.c:178: xc_dom_boot_domU_map: failed to >> mmap domU pages 0x1000+0x1062 [mmap, errno=22 (Invalid argument)]: >> Internal error > This is even more strange. I can't seem to make a connection to > the changes in said commit at all. And I did go through p2m-pt.c's > relevant code another time this morning, without spotting any > possible oversight by Igor. IOW I'm now really curious what it is > that I'm not seeing (and that's apparently NPT-specific). And you haven't been able to reproduce this? I see this fail on two AMD systems (different processor families). What's interesting (I just noticed this) is that while PVH fails in the same manner, HVM crashes differently. The second crash is (d11) xen: copy e820... (XEN) d11v0 Triple fault - invoking HVM shutdown action 1 (XEN) *** Dumping Dom11 vcpu#0 state: *** (XEN) ----[ Xen-4.9-rc x86_64 debug=n Tainted: C ]---- (XEN) CPU: 0 (XEN) RIP: 0008:[<00000000000da54c>] (XEN) RFLAGS: 0000000000000093 CONTEXT: hvm guest (d11v0) (XEN) rax: 000000008ee08e90 rbx: 000000008ee08ec0 rcx: 00000000ffffffff (XEN) rdx: 0000000000006f74 rsi: 000000009ea91ce8 rdi: 0000000000000000 (XEN) rbp: 0000000000006fd8 rsp: 0000000000006f64 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) cr3: 0000000000000000 cr2: 0000000000000000 (XEN) ds: 0010 es: 0010 fs: 0010 gs: 0010 ss: 0010 cs: 0008 so paging is off and it dies not in hvmloader. And this: diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index c6ec1a4..0051623 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -560,7 +560,7 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, { if ( hap_enabled(d) ) { - unsigned long fn_mask = !mfn_eq(mfn, INVALID_MFN) ? + unsigned long fn_mask = (!mfn_eq(mfn, INVALID_MFN) || 1)? (gfn | mfn_x(mfn) | todo) : (gfn | todo); order = (!(fn_mask & ((1ul << PAGE_ORDER_1G) - 1)) && makes the problem go away. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |