Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 10/22/18 11:48 PM, Tamas K Lengyel wrote:
> On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>
>> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
>>> On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
>>> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>
>>>> Hello,
>>>>
>>>> This series aims to prevent the display from freezing when
>>>> enabling altp2m and switching to a new view (and assorted problems
>>>> when resizing the display).
>>>>
>>>> The first patch propagates ept.ad changes to all active altp2ms,
>>>> and the second one allocates a new logdirty rangeset for each
>>>> new altp2m, and propagates (under lock) changes to all p2ms.
>>>>
>>>> The first patch is the same as:
>>>> [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
>>>> but as it is now required for the second one to apply cleanly, it
>>>> has been resent as part of this series.
>>>>
>>>> [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
>>>> [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
>>>
>>> Hi Razvan,
>>> I would be happy to give this a spin, can you push it as a git branch 
>>> somewhere?
>>
>> Sure, here you go:
>>
>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1
> 
> I ran into this crash when my config incorrectly pointed to a
> non-valid disk location:
> 
> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> (XEN) ----[ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]----
> (XEN) CPU:    4
> (XEN) RIP:    e008:[<ffff82d08033f40c>] p2m_uninit_altp2m_ept+0x29/0x2b
> (XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
> (XEN) rax: ffff83046d27802c   rbx: ffff8304558dd880   rcx: 0000000000000000
> (XEN) rdx: ffff83046d277fff   rsi: 00000000004680c0   rdi: 0000000000000000
> (XEN) rbp: ffff83046d277d60   rsp: ffff83046d277d50   r8:  ffff82d0809304a0
> (XEN) r9:  0000000000455940   r10: ffff82e008d01000   r11: 0000000000000017
> (XEN) r12: ffff8304558dd880   r13: ffff8304558df830   r14: ffff8304558df000
> (XEN) r15: fffffffffffffff8   cr0: 000000008005003b   cr4: 00000000003526e0
> (XEN) cr3: 000000005da16000   cr2: ffff880456cd6e80
> (XEN) fsb: 0000000000000000   gsb: ffff880467f40000   gss: 0000000000000000
> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <ffff82d08033f40c> (p2m_uninit_altp2m_ept+0x29/0x2b):
> (XEN)  00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48 8d 
> 05
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08033f40c>] p2m_uninit_altp2m_ept+0x29/0x2b
> (XEN)    [<ffff82d0803305ab>] p2m.c#p2m_teardown_altp2m+0x36/0x52
> (XEN)    [<ffff82d0803331b5>] p2m_final_teardown+0x11/0x28
> (XEN)    [<ffff82d08034509c>] paging_final_teardown+0x2e/0x3c
> (XEN)    [<ffff82d080276439>] arch_domain_destroy+0x50/0xa1
> (XEN)    [<ffff82d08020595c>] domain.c#complete_domain_destroy+0x86/0x159
> (XEN)    [<ffff82d080228f4f>] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
> (XEN)    [<ffff82d08023ae6b>] softirq.c#__do_softirq+0x71/0x9a
> (XEN)    [<ffff82d08023aede>] do_softirq+0x13/0x15
> (XEN)    [<ffff82d080275068>] domain.c#idle_loop+0x63/0xb9
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 4:
> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> (XEN) ****************************************

Right, that one I've also come across now, that will be fixed in the
next series as a result of doing what Andrew has suggested, which is to say:

"Please make all destroy functions idempotent.  i.e.

if ( p2m->sync.logdirty_ranges )
{
    rangeset_destroy(p2m->sync.logdirty_ranges);
    p2m->sync.logdirty_ranges = NULL;
}

and use this destroy function in the cleanup path of init()."

> With the config fixed it boots but when I run DRAKVUF on the domain I
> get the following crash:
> 
> (XEN) ----[ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<000000007bdb630c>] 000000007bdb630c
> (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor (d0v5)
> (XEN) rax: 00000000ee138470   rbx: 0000000000000000   rcx: 000000008000b098
> (XEN) rdx: 0000000000000cf8   rsi: 0000000000000000   rdi: 000000046d2ef000
> (XEN) rbp: 0000000000000000   rsp: ffff83005da27a10   r8:  0000000000000cf8
> (XEN) r9:  0000000000000cf8   r10: ffff83005da27ab8   r11: ffff83005da27a08
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000065
> (XEN) r15: 00000000000005a7   cr0: 0000000080050033   cr4: 0000000000372660
> (XEN) cr3: 000000046d2ef000   cr2: 00000000ee138470
> (XEN) fsb: 00007fe46d97bbc0   gsb: ffff880467f40000   gss: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <000000007bdb630c> (000000007bdb630c):
> (XEN)  80 74 0b 05 70 84 00 00 <c7> 00 00 00 00 e0 80 3d 7a 34 00 00 00 75 64 
> 48
> (XEN) Xen stack trace from rsp=ffff83005da27a10:(XEN) Xen stack trace
> from rsp=ffff83005da27a10:
> (XEN)    0000000000000000 0000000000000065 ffff83005da27a50 ffff82d08037aafc
> (XEN)    00000000fffffffe ffff82d08037ae14 0000000000000000 ffff83005da27a90
> (XEN)    0000000000372660 000000046d2ef000 0000000393e91000 ffff82d0809602b0
> (XEN)    000000fe00000000 ffff82d0802a3b98 ffffffffffffffff ffff83005da27ab8
> (XEN)    ffff83005da27b08 ffff82d0802a3511 ffff82d08046b028 ffff83005da27b08
> (XEN)    ffff82d0802a3511 ffff83005da27fff 0000138800000292 000082d0808176a0
> (XEN)    0000000000000000 ffff82d08023b889 0000000000000292 ffff82d08046b028
> (XEN)    ffff82d080451ac8 ffff82d080454af2 00000000000005a7 ffff83005da27b78
> (XEN)    ffff82d080251d6f ffff82d080250fcd 0000000000000028 ffff83005da27b88
> (XEN)    ffff83005da27b38 000000000000e010 ffff82d080454c73 ffff82d080451ac8
> (XEN)    ffff82d080454af2 00000000000005a7 0000000000000030 ffff83005da27bf8
> (XEN)    ffff82d080454c73 ffff83005da27be8 ffff82d0802aaebc ffff82d08033f3dc
> (XEN)    ffff82d080451ac8 ffff82d08037d969 ffff82d08037d95d ffff82d08037d969
> (XEN)    0b0f82d08037d95d ffff82d08037d969 ffff83005fe5b000 0000000000000000
> (XEN)    0000000000000000 ffff83005da27fff 0000000000000000 00007cffa25d83e7
> (XEN)    ffff82d08037da2d deadbeefdeadf00d ffff83018caf2530 ffff83005da27d38
> (XEN)    ffff83040a492830 ffff83005da27cc8 ffff83040bab2880 0000000000000000
> (XEN)    0000000000000000 deadbeefdeadf00d deadbeefdeadf00d 0000000000000000
> (XEN)    0000000000000000 ffff830451835000 0000000000000000 ffff83040a492000
> (XEN)    0000000600000000 ffff82d08033f3da 000000000000e008 0000000000010282
> (XEN) Xen call trace:
> (XEN)    [<000000007bdb630c>] 000000007bdb630c
> (XEN)
> (XEN) Pagetable walk from 00000000ee138470:
> (XEN)  L4[0x000] = 000000046d2ee063 ffffffffffffffff
> (XEN)  L3[0x003] = 000000005da11063 ffffffffffffffff
> (XEN)  L2[0x170] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0002]
> (XEN) Faulting linear address: 00000000ee138470
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...

This one I'm not sure about. What does your introspection agent do at
that point?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel