[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.