Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message- > From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: 13 July 2015 13:08 > To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > Cc: Keir (Xen.org); Jan Beulich > Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation > > On 07/13/2015 03:04 PM, Paul Durrant wrote: > >> -Original Message- > >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > >> boun...@lists.xen.org] On Behalf Of Paul Durrant > >> Sent: 13 July 2015 11:12 > >> To: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org > >> Cc: Keir (Xen.org); Jan Beulich > >> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with > emulation > >> > >>> -Original Message- > >>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > >>> Sent: 13 July 2015 10:42 > >>> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > >>> Cc: Keir (Xen.org); Jan Beulich > >>> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with > emulation > >>> > >>> On 07/13/2015 12:05 PM, Paul Durrant wrote: > >>>>> -Original Message- > >>>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > >>>>> Sent: 13 July 2015 10:03 > >>>>> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > >>>>> Cc: Keir (Xen.org); Jan Beulich > >>>>> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with > >>> emulation > >>>>> > >>>>> On 07/13/2015 12:01 PM, Paul Durrant wrote: > >>>>>>> -Original Message- > >>>>>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > >>>>>>> Sent: 13 July 2015 09:50 > >>>>>>> To: Andrew Cooper; xen-devel@lists.xen.org > >>>>>>> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant > >>>>>>> Subject: Re: Deadlock in stdvga_mem_accept() with emulation > >>>>>>> > >>>>>>> On 07/13/2015 11:10 AM, Andrew Cooper wrote: > >>>>>>>> On 13/07/2015 08:48, Razvan Cojocaru wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> I'm battling the following hypervisor crash with current staging: > >>>>>>>>> > >>>>>>>>> (d2) Invoking ROMBIOS ... > >>>>>>>>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > >>>>>>>>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert > >> Exp > >>> $ > >>>>>>>>> (XEN) Watchdog timer detects that CPU7 is stuck! > >>>>>>>>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > >>>>>>>>> (XEN) CPU:7 > >>>>>>>>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > >>>>>>>>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > >>>>>>>>> (XEN) rax: c11d rbx: 83041e687970 rcx: > >>>>>>> c11e > >>>>>>>>> (XEN) rdx: 83041e687970 rsi: c11e rdi: > >>>>> 83041e687978 > >>>>>>>>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > >>>>>>> > >>>>>>>>> (XEN) r9: r10: 82d08028c3c0 r11: > >>>>>>> > >>>>>>>>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: > >>>>> 83040eb37278 > >>>>>>>>> (XEN) r15: 000c253f cr0: 8005003b cr4: > >>>>>>> 001526e0 > >>>>>>>>> (XEN) cr3: 0004054a cr2: > >>>>>>>>> (XEN) ds: es: fs: gs: ss: cs: > >>>>>>>>> e008 > >>>>>>>>> (XEN) Xen stack trace from rsp=83040eb37200: > >>>>>>>>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 > >>>>>>> 0282 > >>>>>>>>> (XEN)0008 830403791bf0 83041e687000 > >>>>>>> 83040eb37268 &g
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 03:04 PM, Paul Durrant wrote: >> -Original Message- >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- >> boun...@lists.xen.org] On Behalf Of Paul Durrant >> Sent: 13 July 2015 11:12 >> To: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org >> Cc: Keir (Xen.org); Jan Beulich >> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation >> >>> -Original Message- >>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] >>> Sent: 13 July 2015 10:42 >>> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org >>> Cc: Keir (Xen.org); Jan Beulich >>> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation >>> >>> On 07/13/2015 12:05 PM, Paul Durrant wrote: >>>>> -Original Message- >>>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] >>>>> Sent: 13 July 2015 10:03 >>>>> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org >>>>> Cc: Keir (Xen.org); Jan Beulich >>>>> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with >>> emulation >>>>> >>>>> On 07/13/2015 12:01 PM, Paul Durrant wrote: >>>>>>> -Original Message- >>>>>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] >>>>>>> Sent: 13 July 2015 09:50 >>>>>>> To: Andrew Cooper; xen-devel@lists.xen.org >>>>>>> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant >>>>>>> Subject: Re: Deadlock in stdvga_mem_accept() with emulation >>>>>>> >>>>>>> On 07/13/2015 11:10 AM, Andrew Cooper wrote: >>>>>>>> On 13/07/2015 08:48, Razvan Cojocaru wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm battling the following hypervisor crash with current staging: >>>>>>>>> >>>>>>>>> (d2) Invoking ROMBIOS ... >>>>>>>>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes >>>>>>>>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert >> Exp >>> $ >>>>>>>>> (XEN) Watchdog timer detects that CPU7 is stuck! >>>>>>>>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] >>>>>>>>> (XEN) CPU:7 >>>>>>>>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 >>>>>>>>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) >>>>>>>>> (XEN) rax: c11d rbx: 83041e687970 rcx: >>>>>>> c11e >>>>>>>>> (XEN) rdx: 83041e687970 rsi: c11e rdi: >>>>> 83041e687978 >>>>>>>>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: >>>>>>> >>>>>>>>> (XEN) r9: r10: 82d08028c3c0 r11: >>>>>>> >>>>>>>>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: >>>>> 83040eb37278 >>>>>>>>> (XEN) r15: 000c253f cr0: 8005003b cr4: >>>>>>> 001526e0 >>>>>>>>> (XEN) cr3: 0004054a cr2: >>>>>>>>> (XEN) ds: es: fs: gs: ss: cs: e008 >>>>>>>>> (XEN) Xen stack trace from rsp=83040eb37200: >>>>>>>>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 >>>>>>> 0282 >>>>>>>>> (XEN)0008 830403791bf0 83041e687000 >>>>>>> 83040eb37268 >>>>>>>>> (XEN)82d0801cb23a 000c253f 8300d85fc000 >>>>>>> 0001 >>>>>>>>> (XEN)00c2 83040eb37298 82d0801cb410 >>>>>>> 000c253f >>>>>>>>> (XEN) 00010001 0100 >>>>>>> 83040eb37328 >>>>>>>>> (XEN)82d0801c2403 83040eb37394 83040eb3 >>>>>>> >>>>>>>>> (XEN)83040eb37360 00c2 8304054cb000 >>>>>>> 0
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Paul Durrant > Sent: 13 July 2015 11:12 > To: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org > Cc: Keir (Xen.org); Jan Beulich > Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation > > > -Original Message- > > From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > > Sent: 13 July 2015 10:42 > > To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > > Cc: Keir (Xen.org); Jan Beulich > > Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation > > > > On 07/13/2015 12:05 PM, Paul Durrant wrote: > > >> -Original Message- > > >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > > >> Sent: 13 July 2015 10:03 > > >> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > > >> Cc: Keir (Xen.org); Jan Beulich > > >> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with > > emulation > > >> > > >> On 07/13/2015 12:01 PM, Paul Durrant wrote: > > >>>> -Original Message- > > >>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > > >>>> Sent: 13 July 2015 09:50 > > >>>> To: Andrew Cooper; xen-devel@lists.xen.org > > >>>> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant > > >>>> Subject: Re: Deadlock in stdvga_mem_accept() with emulation > > >>>> > > >>>> On 07/13/2015 11:10 AM, Andrew Cooper wrote: > > >>>>> On 13/07/2015 08:48, Razvan Cojocaru wrote: > > >>>>>> Hello, > > >>>>>> > > >>>>>> I'm battling the following hypervisor crash with current staging: > > >>>>>> > > >>>>>> (d2) Invoking ROMBIOS ... > > >>>>>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > > >>>>>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert > Exp > > $ > > >>>>>> (XEN) Watchdog timer detects that CPU7 is stuck! > > >>>>>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > > >>>>>> (XEN) CPU:7 > > >>>>>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > > >>>>>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > > >>>>>> (XEN) rax: c11d rbx: 83041e687970 rcx: > > >>>> c11e > > >>>>>> (XEN) rdx: 83041e687970 rsi: c11e rdi: > > >> 83041e687978 > > >>>>>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > > >>>> > > >>>>>> (XEN) r9: r10: 82d08028c3c0 r11: > > >>>> > > >>>>>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: > > >> 83040eb37278 > > >>>>>> (XEN) r15: 000c253f cr0: 8005003b cr4: > > >>>> 001526e0 > > >>>>>> (XEN) cr3: 0004054a cr2: > > >>>>>> (XEN) ds: es: fs: gs: ss: cs: e008 > > >>>>>> (XEN) Xen stack trace from rsp=83040eb37200: > > >>>>>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 > > >>>> 0282 > > >>>>>> (XEN)0008 830403791bf0 83041e687000 > > >>>> 83040eb37268 > > >>>>>> (XEN)82d0801cb23a 000c253f 8300d85fc000 > > >>>> 0001 > > >>>>>> (XEN)00c2 83040eb37298 82d0801cb410 > > >>>> 000c253f > > >>>>>> (XEN) 00010001 0100 > > >>>> 83040eb37328 > > >>>>>> (XEN)82d0801c2403 83040eb37394 83040eb3 > > >>>> > > >>>>>> (XEN)83040eb37360 00c2 8304054cb000 > > >>>> 053f > > >>>>>> (XEN)0002 83040eb373f4 > > >>>> 00c2 > > >>>>>> (XEN)83040eb373d8 000
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message- > From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: 13 July 2015 10:42 > To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > Cc: Keir (Xen.org); Jan Beulich > Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation > > On 07/13/2015 12:05 PM, Paul Durrant wrote: > >> -Original Message- > >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > >> Sent: 13 July 2015 10:03 > >> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > >> Cc: Keir (Xen.org); Jan Beulich > >> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with > emulation > >> > >> On 07/13/2015 12:01 PM, Paul Durrant wrote: > >>>> -Original Message- > >>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > >>>> Sent: 13 July 2015 09:50 > >>>> To: Andrew Cooper; xen-devel@lists.xen.org > >>>> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant > >>>> Subject: Re: Deadlock in stdvga_mem_accept() with emulation > >>>> > >>>> On 07/13/2015 11:10 AM, Andrew Cooper wrote: > >>>>> On 13/07/2015 08:48, Razvan Cojocaru wrote: > >>>>>> Hello, > >>>>>> > >>>>>> I'm battling the following hypervisor crash with current staging: > >>>>>> > >>>>>> (d2) Invoking ROMBIOS ... > >>>>>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > >>>>>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp > $ > >>>>>> (XEN) Watchdog timer detects that CPU7 is stuck! > >>>>>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > >>>>>> (XEN) CPU:7 > >>>>>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > >>>>>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > >>>>>> (XEN) rax: c11d rbx: 83041e687970 rcx: > >>>> c11e > >>>>>> (XEN) rdx: 83041e687970 rsi: c11e rdi: > >> 83041e687978 > >>>>>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > >>>> > >>>>>> (XEN) r9: r10: 82d08028c3c0 r11: > >>>> > >>>>>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: > >> 83040eb37278 > >>>>>> (XEN) r15: 000c253f cr0: 8005003b cr4: > >>>> 001526e0 > >>>>>> (XEN) cr3: 0004054a cr2: > >>>>>> (XEN) ds: es: fs: gs: ss: cs: e008 > >>>>>> (XEN) Xen stack trace from rsp=83040eb37200: > >>>>>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 > >>>> 0282 > >>>>>> (XEN)0008 830403791bf0 83041e687000 > >>>> 83040eb37268 > >>>>>> (XEN)82d0801cb23a 000c253f 8300d85fc000 > >>>> 0001 > >>>>>> (XEN)00c2 83040eb37298 82d0801cb410 > >>>> 000c253f > >>>>>> (XEN) 00010001 0100 > >>>> 83040eb37328 > >>>>>> (XEN)82d0801c2403 83040eb37394 83040eb3 > >>>> > >>>>>> (XEN)83040eb37360 00c2 8304054cb000 > >>>> 053f > >>>>>> (XEN)0002 83040eb373f4 > >>>> 00c2 > >>>>>> (XEN)83040eb373d8 > >>>> 82d08028c620 > >>>>>> (XEN) 83040eb37338 82d0801c3e5d > >>>> 83040eb37398 > >>>>>> (XEN)82d0801cb107 00010eb37394 830403791bf0 > >>>> 830403791bf0 > >>>>>> (XEN)83041e687000 83040eb37398 830403791bf0 > >>>> 0001 > >>>>>> (XEN)83040eb373d8 0001 000c253f > >>>> 83040eb373c8 > >>>>>> (XEN)82d0801cb291 83040eb37b30 8300d85fc000 > >>>> 0001 > >>&
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 12:05 PM, Paul Durrant wrote: >> -Original Message- >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] >> Sent: 13 July 2015 10:03 >> To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org >> Cc: Keir (Xen.org); Jan Beulich >> Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation >> >> On 07/13/2015 12:01 PM, Paul Durrant wrote: >>>> -Original Message- >>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] >>>> Sent: 13 July 2015 09:50 >>>> To: Andrew Cooper; xen-devel@lists.xen.org >>>> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant >>>> Subject: Re: Deadlock in stdvga_mem_accept() with emulation >>>> >>>> On 07/13/2015 11:10 AM, Andrew Cooper wrote: >>>>> On 13/07/2015 08:48, Razvan Cojocaru wrote: >>>>>> Hello, >>>>>> >>>>>> I'm battling the following hypervisor crash with current staging: >>>>>> >>>>>> (d2) Invoking ROMBIOS ... >>>>>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes >>>>>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ >>>>>> (XEN) Watchdog timer detects that CPU7 is stuck! >>>>>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] >>>>>> (XEN) CPU:7 >>>>>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 >>>>>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) >>>>>> (XEN) rax: c11d rbx: 83041e687970 rcx: >>>> c11e >>>>>> (XEN) rdx: 83041e687970 rsi: c11e rdi: >> 83041e687978 >>>>>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: >>>> >>>>>> (XEN) r9: r10: 82d08028c3c0 r11: >>>> >>>>>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: >> 83040eb37278 >>>>>> (XEN) r15: 000c253f cr0: 8005003b cr4: >>>> 001526e0 >>>>>> (XEN) cr3: 0004054a cr2: >>>>>> (XEN) ds: es: fs: gs: ss: cs: e008 >>>>>> (XEN) Xen stack trace from rsp=83040eb37200: >>>>>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 >>>> 0282 >>>>>> (XEN)0008 830403791bf0 83041e687000 >>>> 83040eb37268 >>>>>> (XEN)82d0801cb23a 000c253f 8300d85fc000 >>>> 0001 >>>>>> (XEN)00c2 83040eb37298 82d0801cb410 >>>> 000c253f >>>>>> (XEN) 00010001 0100 >>>> 83040eb37328 >>>>>> (XEN)82d0801c2403 83040eb37394 83040eb3 >>>> >>>>>> (XEN)83040eb37360 00c2 8304054cb000 >>>> 053f >>>>>> (XEN)0002 83040eb373f4 >>>> 00c2 >>>>>> (XEN)83040eb373d8 >>>> 82d08028c620 >>>>>> (XEN) 83040eb37338 82d0801c3e5d >>>> 83040eb37398 >>>>>> (XEN)82d0801cb107 00010eb37394 830403791bf0 >>>> 830403791bf0 >>>>>> (XEN)83041e687000 83040eb37398 830403791bf0 >>>> 0001 >>>>>> (XEN)83040eb373d8 0001 000c253f >>>> 83040eb373c8 >>>>>> (XEN)82d0801cb291 83040eb37b30 8300d85fc000 >>>> 0001 >>>>>> (XEN) 83040eb37428 82d0801bb440 >>>> 000a0001 >>>>>> (XEN)000c253f 00010001 0111 >>>> 83040eb37478 >>>>>> (XEN)0001 >>>> 0001 >>>>>> (XEN)0001 83040eb374a8 82d0801bc0b9 >>>> 0001 >>>>>> (XEN)000c253f 8300d85fc000 000a0001 >>>> 0100 >>>>>> (XEN)83040eb37728 82e00819dc60 >>>>
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
>>> On 13.07.15 at 11:30, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 13 July 2015 10:28
>> To: Paul Durrant
>> Cc: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org; Keir
>> (Xen.org)
>> Subject: RE: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
>>
>> >>> On 13.07.15 at 11:05, wrote:
>> > --- a/xen/arch/x86/hvm/stdvga.c
>> > +++ b/xen/arch/x86/hvm/stdvga.c
>> > @@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
>> > hvm_io_handle
>> > {
>> > struct hvm_hw_stdvga *s = ¤t->domain-
>> >arch.hvm_domain.stdvga;
>> >
>> > +/*
>> > + * The range check must be done without taking any locks, to avoid
>> > + * deadlock when hvm_mmio_internal() is called from
>> > + * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
>> > + */
>> > +if ( (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
>> > + (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE))
>> )
>> > +return 0;
>> > +
>> > spin_lock(&s->lock);
>> >
>> > -if ( !s->stdvga ||
>> > - (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
>> > - (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE)) )
>> > +if ( !s->stdvga )
>> > goto reject;
>> >
>> > if ( p->dir == IOREQ_WRITE && p->count > 1 )
>>
>> But won't the problem continue to exist if the address falls within the
>> VGA range? I.e. isn't the problem that the two uses of
>> hvm_mmio_internal() are quite different - while
>> hvm_hap_nested_page_fault() immediately afterwards calls a
>> handle_mmio() variant (which would even seem to call for the lock not
>> getting dropped between them), __hvm_copy() uses it as just a check.
>>
>> I.e. perhaps better to convert the lock to a recursive one?
>
> I think we are ok because the stdvga model will never actually accept the
> I/O since MMIO <-> MMIO rep mov is explicitly disallowed.
True, for now at least.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 July 2015 10:28
> To: Paul Durrant
> Cc: Razvan Cojocaru; Andrew Cooper; xen-devel@lists.xen.org; Keir
> (Xen.org)
> Subject: RE: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
>
> >>> On 13.07.15 at 11:05, wrote:
> > --- a/xen/arch/x86/hvm/stdvga.c
> > +++ b/xen/arch/x86/hvm/stdvga.c
> > @@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
> > hvm_io_handle
> > {
> > struct hvm_hw_stdvga *s = ¤t->domain-
> >arch.hvm_domain.stdvga;
> >
> > +/*
> > + * The range check must be done without taking any locks, to avoid
> > + * deadlock when hvm_mmio_internal() is called from
> > + * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
> > + */
> > +if ( (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
> > + (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE))
> )
> > +return 0;
> > +
> > spin_lock(&s->lock);
> >
> > -if ( !s->stdvga ||
> > - (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
> > - (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE)) )
> > +if ( !s->stdvga )
> > goto reject;
> >
> > if ( p->dir == IOREQ_WRITE && p->count > 1 )
>
> But won't the problem continue to exist if the address falls within the
> VGA range? I.e. isn't the problem that the two uses of
> hvm_mmio_internal() are quite different - while
> hvm_hap_nested_page_fault() immediately afterwards calls a
> handle_mmio() variant (which would even seem to call for the lock not
> getting dropped between them), __hvm_copy() uses it as just a check.
>
> I.e. perhaps better to convert the lock to a recursive one?
>
I think we are ok because the stdvga model will never actually accept the I/O
since MMIO <-> MMIO rep mov is explicitly disallowed.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
>>> On 13.07.15 at 11:05, wrote:
> --- a/xen/arch/x86/hvm/stdvga.c
> +++ b/xen/arch/x86/hvm/stdvga.c
> @@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
> hvm_io_handle
> {
> struct hvm_hw_stdvga *s = ¤t->domain->arch.hvm_domain.stdvga;
>
> +/*
> + * The range check must be done without taking any locks, to avoid
> + * deadlock when hvm_mmio_internal() is called from
> + * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
> + */
> +if ( (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
> + (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE)) )
> +return 0;
> +
> spin_lock(&s->lock);
>
> -if ( !s->stdvga ||
> - (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
> - (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE)) )
> +if ( !s->stdvga )
> goto reject;
>
> if ( p->dir == IOREQ_WRITE && p->count > 1 )
But won't the problem continue to exist if the address falls within the
VGA range? I.e. isn't the problem that the two uses of
hvm_mmio_internal() are quite different - while
hvm_hap_nested_page_fault() immediately afterwards calls a
handle_mmio() variant (which would even seem to call for the lock not
getting dropped between them), __hvm_copy() uses it as just a check.
I.e. perhaps better to convert the lock to a recursive one?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message- > From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: 13 July 2015 10:03 > To: Paul Durrant; Andrew Cooper; xen-devel@lists.xen.org > Cc: Keir (Xen.org); Jan Beulich > Subject: Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation > > On 07/13/2015 12:01 PM, Paul Durrant wrote: > >> -Original Message- > >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > >> Sent: 13 July 2015 09:50 > >> To: Andrew Cooper; xen-devel@lists.xen.org > >> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant > >> Subject: Re: Deadlock in stdvga_mem_accept() with emulation > >> > >> On 07/13/2015 11:10 AM, Andrew Cooper wrote: > >>> On 13/07/2015 08:48, Razvan Cojocaru wrote: > >>>> Hello, > >>>> > >>>> I'm battling the following hypervisor crash with current staging: > >>>> > >>>> (d2) Invoking ROMBIOS ... > >>>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > >>>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ > >>>> (XEN) Watchdog timer detects that CPU7 is stuck! > >>>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > >>>> (XEN) CPU:7 > >>>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > >>>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > >>>> (XEN) rax: c11d rbx: 83041e687970 rcx: > >> c11e > >>>> (XEN) rdx: 83041e687970 rsi: c11e rdi: > 83041e687978 > >>>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > >> > >>>> (XEN) r9: r10: 82d08028c3c0 r11: > >> > >>>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: > 83040eb37278 > >>>> (XEN) r15: 000c253f cr0: 8005003b cr4: > >> 001526e0 > >>>> (XEN) cr3: 0004054a cr2: > >>>> (XEN) ds: es: fs: gs: ss: cs: e008 > >>>> (XEN) Xen stack trace from rsp=83040eb37200: > >>>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 > >> 0282 > >>>> (XEN)0008 830403791bf0 83041e687000 > >> 83040eb37268 > >>>> (XEN)82d0801cb23a 000c253f 8300d85fc000 > >> 0001 > >>>> (XEN)00c2 83040eb37298 82d0801cb410 > >> 000c253f > >>>> (XEN) 00010001 0100 > >> 83040eb37328 > >>>> (XEN)82d0801c2403 83040eb37394 83040eb3 > >> > >>>> (XEN)83040eb37360 00c2 8304054cb000 > >> 053f > >>>> (XEN)0002 83040eb373f4 > >> 00c2 > >>>> (XEN)83040eb373d8 > >> 82d08028c620 > >>>> (XEN) 83040eb37338 82d0801c3e5d > >> 83040eb37398 > >>>> (XEN)82d0801cb107 00010eb37394 830403791bf0 > >> 830403791bf0 > >>>> (XEN)83041e687000 83040eb37398 830403791bf0 > >> 0001 > >>>> (XEN)83040eb373d8 0001 000c253f > >> 83040eb373c8 > >>>> (XEN)82d0801cb291 83040eb37b30 8300d85fc000 > >> 0001 > >>>> (XEN) 83040eb37428 82d0801bb440 > >> 000a0001 > >>>> (XEN)000c253f 00010001 0111 > >> 83040eb37478 > >>>> (XEN)0001 > >> 0001 > >>>> (XEN)0001 83040eb374a8 82d0801bc0b9 > >> 0001 > >>>> (XEN)000c253f 8300d85fc000 000a0001 > >> 0100 > >>>> (XEN)83040eb37728 82e00819dc60 > >> 83040eb374c8 > >>>> (XEN) Xen call trace: > >>>> (XEN)[] _spin_lock+0x31/0x54 > >>>> (XEN)[] stdvga_mem_accept+0x3b/0x125 > >>>> (XEN)[] hvm_find_io_handler+0x68/0x8a > >>>> (
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 12:01 PM, Paul Durrant wrote: >> -Original Message- >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] >> Sent: 13 July 2015 09:50 >> To: Andrew Cooper; xen-devel@lists.xen.org >> Cc: Keir (Xen.org); Jan Beulich; Paul Durrant >> Subject: Re: Deadlock in stdvga_mem_accept() with emulation >> >> On 07/13/2015 11:10 AM, Andrew Cooper wrote: >>> On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: >> c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: >> (XEN) r9: r10: 82d08028c3c0 r11: >> (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: >> 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 >> 0282 (XEN)0008 830403791bf0 83041e687000 >> 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 >> 0001 (XEN)00c2 83040eb37298 82d0801cb410 >> 000c253f (XEN) 00010001 0100 >> 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 >> (XEN)83040eb37360 00c2 8304054cb000 >> 053f (XEN)0002 83040eb373f4 >> 00c2 (XEN)83040eb373d8 >> 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d >> 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 >> 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 >> 0001 (XEN)83040eb373d8 0001 000c253f >> 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 >> 0001 (XEN) 83040eb37428 82d0801bb440 >> 000a0001 (XEN)000c253f 00010001 0111 >> 83040eb37478 (XEN)0001 >> 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 >> 0001 (XEN)000c253f 8300d85fc000 000a0001 >> 0100 (XEN)83040eb37728 82e00819dc60 >> 83040eb374c8 (XEN) Xen call trace: (XEN)[] _spin_lock+0x31/0x54 (XEN)[] stdvga_mem_accept+0x3b/0x125 (XEN)[] hvm_find_io_handler+0x68/0x8a (XEN)[] hvm_mmio_internal+0x37/0x67 (XEN)[] __hvm_copy+0xe9/0x37d (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[] hvm_io_intercept+0x35/0x5b (XEN)[] hvmemul_do_io+0x1ff/0x2c1 (XEN)[] hvmemul_do_io_addr+0x117/0x163 (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[] hvmemul_rep_movs+0x1ef/0x335 (XEN)[] x86_emulate+0x56c9/0x13088 (XEN)[] _hvm_emulate_one+0x186/0x281 (XEN)[] hvm_emulate_one+0x10/0x12 (XEN)[] handle_mmio+0x54/0xd2 (XEN)[] handle_mmio_with_translation+0x44/0x46 (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[] vmx_vmexit_handler+0x150e/0x188d (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 7: (XEN) FATAL TRAP: vector = 2 (nmi) (XEN) [error_code=] (XEN) At first I thought it was caused by V5 of the vm_event-based introspection series, but I've rolled it back enough to apply V4 on top of it (which has been thoroughly tested on Thursday), and it still happens, so this would at least appear to be unrelated at this point (other than the fact that our use case is maybe somewhat unusual with heavy emulation). I'll keep digging, but since this is a busy time for Xen I thought I'd issue a heads-up
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message- > From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: 13 July 2015 09:50 > To: Andrew Cooper; xen-devel@lists.xen.org > Cc: Keir (Xen.org); Jan Beulich; Paul Durrant > Subject: Re: Deadlock in stdvga_mem_accept() with emulation > > On 07/13/2015 11:10 AM, Andrew Cooper wrote: > > On 13/07/2015 08:48, Razvan Cojocaru wrote: > >> Hello, > >> > >> I'm battling the following hypervisor crash with current staging: > >> > >> (d2) Invoking ROMBIOS ... > >> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > >> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ > >> (XEN) Watchdog timer detects that CPU7 is stuck! > >> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > >> (XEN) CPU:7 > >> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > >> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > >> (XEN) rax: c11d rbx: 83041e687970 rcx: > c11e > >> (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 > >> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > > >> (XEN) r9: r10: 82d08028c3c0 r11: > > >> (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 > >> (XEN) r15: 000c253f cr0: 8005003b cr4: > 001526e0 > >> (XEN) cr3: 0004054a cr2: > >> (XEN) ds: es: fs: gs: ss: cs: e008 > >> (XEN) Xen stack trace from rsp=83040eb37200: > >> (XEN)83040eb37278 83040eb37238 82d0801d09b6 > 0282 > >> (XEN)0008 830403791bf0 83041e687000 > 83040eb37268 > >> (XEN)82d0801cb23a 000c253f 8300d85fc000 > 0001 > >> (XEN)00c2 83040eb37298 82d0801cb410 > 000c253f > >> (XEN) 00010001 0100 > 83040eb37328 > >> (XEN)82d0801c2403 83040eb37394 83040eb3 > > >> (XEN)83040eb37360 00c2 8304054cb000 > 053f > >> (XEN)0002 83040eb373f4 > 00c2 > >> (XEN)83040eb373d8 > 82d08028c620 > >> (XEN) 83040eb37338 82d0801c3e5d > 83040eb37398 > >> (XEN)82d0801cb107 00010eb37394 830403791bf0 > 830403791bf0 > >> (XEN)83041e687000 83040eb37398 830403791bf0 > 0001 > >> (XEN)83040eb373d8 0001 000c253f > 83040eb373c8 > >> (XEN)82d0801cb291 83040eb37b30 8300d85fc000 > 0001 > >> (XEN) 83040eb37428 82d0801bb440 > 000a0001 > >> (XEN)000c253f 00010001 0111 > 83040eb37478 > >> (XEN)0001 > 0001 > >> (XEN)0001 83040eb374a8 82d0801bc0b9 > 0001 > >> (XEN)000c253f 8300d85fc000 000a0001 > 0100 > >> (XEN)83040eb37728 82e00819dc60 > 83040eb374c8 > >> (XEN) Xen call trace: > >> (XEN)[] _spin_lock+0x31/0x54 > >> (XEN)[] stdvga_mem_accept+0x3b/0x125 > >> (XEN)[] hvm_find_io_handler+0x68/0x8a > >> (XEN)[] hvm_mmio_internal+0x37/0x67 > >> (XEN)[] __hvm_copy+0xe9/0x37d > >> (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 > >> (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 > >> (XEN)[] hvm_io_intercept+0x35/0x5b > >> (XEN)[] hvmemul_do_io+0x1ff/0x2c1 > >> (XEN)[] hvmemul_do_io_addr+0x117/0x163 > >> (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 > >> (XEN)[] hvmemul_rep_movs+0x1ef/0x335 > >> (XEN)[] x86_emulate+0x56c9/0x13088 > >> (XEN)[] _hvm_emulate_one+0x186/0x281 > >> (XEN)[] hvm_emulate_one+0x10/0x12 > >> (XEN)[] handle_mmio+0x54/0xd2 > >> (XEN)[] handle_mmio_with_translation+0x44/0x46 > >> (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 > >> (XEN)[] vmx_vmexit_handler+0x150e/0x188d > >> (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 > >> (XEN) > >> (XEN) > >> (XEN) > >> (XEN) Panic on CPU 7: > >> (XEN) FATAL TRAP: vector = 2 (nmi) > >> (XEN) [error_code=] > >> (XEN) > >> > >> At first I thought it was caused by V5 of the vm_event-based > >> introspection series, but I've rolled it back enough to apply V4 on top > >> of it (which has been thoroughly tested on Thursday), and it still > >> happens, so this would at least appear to be unrelated at this point > >> (other than the fact that our use case is maybe somewhat unusual with > >> heavy emulation). > >> > >> I'll keep digging, but since this is a busy time for Xen I thought I'd > >> issue a heads-up here as soon as possible, in case the problem is > >> obvious for somebody
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 12:00 PM, Andrew Cooper wrote: > On 13/07/15 09:50, Razvan Cojocaru wrote: >> On 07/13/2015 11:10 AM, Andrew Cooper wrote: >>> On 13/07/2015 08:48, Razvan Cojocaru wrote: Hello, I'm battling the following hypervisor crash with current staging: (d2) Invoking ROMBIOS ... (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ (XEN) Watchdog timer detects that CPU7 is stuck! (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[] _spin_lock+0x31/0x54 (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) (XEN) rax: c11d rbx: 83041e687970 rcx: c11e (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: (XEN) r9: r10: 82d08028c3c0 r11: (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 (XEN) cr3: 0004054a cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=83040eb37200: (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 (XEN)0008 830403791bf0 83041e687000 83040eb37268 (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 (XEN)00c2 83040eb37298 82d0801cb410 000c253f (XEN) 00010001 0100 83040eb37328 (XEN)82d0801c2403 83040eb37394 83040eb3 (XEN)83040eb37360 00c2 8304054cb000 053f (XEN)0002 83040eb373f4 00c2 (XEN)83040eb373d8 82d08028c620 (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 (XEN)83041e687000 83040eb37398 830403791bf0 0001 (XEN)83040eb373d8 0001 000c253f 83040eb373c8 (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 (XEN) 83040eb37428 82d0801bb440 000a0001 (XEN)000c253f 00010001 0111 83040eb37478 (XEN)0001 0001 (XEN)0001 83040eb374a8 82d0801bc0b9 0001 (XEN)000c253f 8300d85fc000 000a0001 0100 (XEN)83040eb37728 82e00819dc60 83040eb374c8 (XEN) Xen call trace: (XEN)[] _spin_lock+0x31/0x54 (XEN)[] stdvga_mem_accept+0x3b/0x125 (XEN)[] hvm_find_io_handler+0x68/0x8a (XEN)[] hvm_mmio_internal+0x37/0x67 (XEN)[] __hvm_copy+0xe9/0x37d (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 (XEN)[] hvm_io_intercept+0x35/0x5b (XEN)[] hvmemul_do_io+0x1ff/0x2c1 (XEN)[] hvmemul_do_io_addr+0x117/0x163 (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 (XEN)[] hvmemul_rep_movs+0x1ef/0x335 (XEN)[] x86_emulate+0x56c9/0x13088 (XEN)[] _hvm_emulate_one+0x186/0x281 (XEN)[] hvm_emulate_one+0x10/0x12 (XEN)[] handle_mmio+0x54/0xd2 (XEN)[] handle_mmio_with_translation+0x44/0x46 (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 (XEN)[] vmx_vmexit_handler+0x150e/0x188d (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 7: (XEN) FATAL TRAP: vector = 2 (nmi) (XEN) [error_code=] (XEN) At first I thought it was caused by V5 of the vm_event-based introspection series, but I've rolled it back enough to apply V4 on top of it (which has been thoroughly tested on Thursday), and it still happens, so this would at least appear to be unrelated at this point (other than the fact that our use case is maybe somewhat unusual with heavy emulation). I'll keep digging, but since this is a busy time for Xen I thought I'd issue a heads-up here as soon as possible, in case the problem is obvious for somebody and it helps getting it fixed sooner. >>> In c/s 3bbaaec09b1b942f5624dee176da6e416d31f982 there is now a >>> d
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 13/07/15 09:50, Razvan Cojocaru wrote: > On 07/13/2015 11:10 AM, Andrew Cooper wrote: >> On 13/07/2015 08:48, Razvan Cojocaru wrote: >>> Hello, >>> >>> I'm battling the following hypervisor crash with current staging: >>> >>> (d2) Invoking ROMBIOS ... >>> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes >>> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ >>> (XEN) Watchdog timer detects that CPU7 is stuck! >>> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] >>> (XEN) CPU:7 >>> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 >>> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) >>> (XEN) rax: c11d rbx: 83041e687970 rcx: c11e >>> (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 >>> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: >>> (XEN) r9: r10: 82d08028c3c0 r11: >>> (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 >>> (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 >>> (XEN) cr3: 0004054a cr2: >>> (XEN) ds: es: fs: gs: ss: cs: e008 >>> (XEN) Xen stack trace from rsp=83040eb37200: >>> (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 >>> (XEN)0008 830403791bf0 83041e687000 83040eb37268 >>> (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 >>> (XEN)00c2 83040eb37298 82d0801cb410 000c253f >>> (XEN) 00010001 0100 83040eb37328 >>> (XEN)82d0801c2403 83040eb37394 83040eb3 >>> (XEN)83040eb37360 00c2 8304054cb000 053f >>> (XEN)0002 83040eb373f4 00c2 >>> (XEN)83040eb373d8 82d08028c620 >>> (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 >>> (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 >>> (XEN)83041e687000 83040eb37398 830403791bf0 0001 >>> (XEN)83040eb373d8 0001 000c253f 83040eb373c8 >>> (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 >>> (XEN) 83040eb37428 82d0801bb440 000a0001 >>> (XEN)000c253f 00010001 0111 83040eb37478 >>> (XEN)0001 0001 >>> (XEN)0001 83040eb374a8 82d0801bc0b9 0001 >>> (XEN)000c253f 8300d85fc000 000a0001 0100 >>> (XEN)83040eb37728 82e00819dc60 83040eb374c8 >>> (XEN) Xen call trace: >>> (XEN)[] _spin_lock+0x31/0x54 >>> (XEN)[] stdvga_mem_accept+0x3b/0x125 >>> (XEN)[] hvm_find_io_handler+0x68/0x8a >>> (XEN)[] hvm_mmio_internal+0x37/0x67 >>> (XEN)[] __hvm_copy+0xe9/0x37d >>> (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 >>> (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 >>> (XEN)[] hvm_io_intercept+0x35/0x5b >>> (XEN)[] hvmemul_do_io+0x1ff/0x2c1 >>> (XEN)[] hvmemul_do_io_addr+0x117/0x163 >>> (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 >>> (XEN)[] hvmemul_rep_movs+0x1ef/0x335 >>> (XEN)[] x86_emulate+0x56c9/0x13088 >>> (XEN)[] _hvm_emulate_one+0x186/0x281 >>> (XEN)[] hvm_emulate_one+0x10/0x12 >>> (XEN)[] handle_mmio+0x54/0xd2 >>> (XEN)[] handle_mmio_with_translation+0x44/0x46 >>> (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 >>> (XEN)[] vmx_vmexit_handler+0x150e/0x188d >>> (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 >>> (XEN) >>> (XEN) >>> (XEN) >>> (XEN) Panic on CPU 7: >>> (XEN) FATAL TRAP: vector = 2 (nmi) >>> (XEN) [error_code=] >>> (XEN) >>> >>> At first I thought it was caused by V5 of the vm_event-based >>> introspection series, but I've rolled it back enough to apply V4 on top >>> of it (which has been thoroughly tested on Thursday), and it still >>> happens, so this would at least appear to be unrelated at this point >>> (other than the fact that our use case is maybe somewhat unusual with >>> heavy emulation). >>> >>> I'll keep digging, but since this is a busy time for Xen I thought I'd >>> issue a heads-up here as soon as possible, in case the problem is >>> obvious for somebody and it helps getting it fixed sooner. >> In c/s 3bbaaec09b1b942f5624dee176da6e416d31f982 there is now a >> deliberate split between stdvga_mem_accept() and stdvga_mem_complete() >> about locking and unlocking the stdvga lock. >> >> At a guess, the previous chain of execution accidentally omitted the >> stdvga_mem_complete() call. > Thanks, I've reverted tha
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
> -Original Message- > From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of > Andrew Cooper > Sent: 13 July 2015 09:11 > To: Razvan Cojocaru; xen-devel@lists.xen.org > Cc: Keir (Xen.org); Jan Beulich; Paul Durrant > Subject: Re: Deadlock in stdvga_mem_accept() with emulation > > On 13/07/2015 08:48, Razvan Cojocaru wrote: > > Hello, > > > > I'm battling the following hypervisor crash with current staging: > > > > (d2) Invoking ROMBIOS ... > > (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > > (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ > > (XEN) Watchdog timer detects that CPU7 is stuck! > > (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > > (XEN) CPU:7 > > (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > > (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > > (XEN) rax: c11d rbx: 83041e687970 rcx: > c11e > > (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 > > (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > > (XEN) r9: r10: 82d08028c3c0 r11: > > (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 > > (XEN) r15: 000c253f cr0: 8005003b cr4: > 001526e0 > > (XEN) cr3: 0004054a cr2: > > (XEN) ds: es: fs: gs: ss: cs: e008 > > (XEN) Xen stack trace from rsp=83040eb37200: > > (XEN)83040eb37278 83040eb37238 82d0801d09b6 > 0282 > > (XEN)0008 830403791bf0 83041e687000 > 83040eb37268 > > (XEN)82d0801cb23a 000c253f 8300d85fc000 > 0001 > > (XEN)00c2 83040eb37298 82d0801cb410 > 000c253f > > (XEN) 00010001 0100 > 83040eb37328 > > (XEN)82d0801c2403 83040eb37394 83040eb3 > > > (XEN)83040eb37360 00c2 8304054cb000 > 053f > > (XEN)0002 83040eb373f4 > 00c2 > > (XEN)83040eb373d8 > 82d08028c620 > > (XEN) 83040eb37338 82d0801c3e5d > 83040eb37398 > > (XEN)82d0801cb107 00010eb37394 830403791bf0 > 830403791bf0 > > (XEN)83041e687000 83040eb37398 830403791bf0 > 0001 > > (XEN)83040eb373d8 0001 000c253f > 83040eb373c8 > > (XEN)82d0801cb291 83040eb37b30 8300d85fc000 > 0001 > > (XEN) 83040eb37428 82d0801bb440 > 000a0001 > > (XEN)000c253f 00010001 0111 > 83040eb37478 > > (XEN)0001 > 0001 > > (XEN)0001 83040eb374a8 82d0801bc0b9 > 0001 > > (XEN)000c253f 8300d85fc000 000a0001 > 0100 > > (XEN)83040eb37728 82e00819dc60 > 83040eb374c8 > > (XEN) Xen call trace: > > (XEN)[] _spin_lock+0x31/0x54 > > (XEN)[] stdvga_mem_accept+0x3b/0x125 > > (XEN)[] hvm_find_io_handler+0x68/0x8a > > (XEN)[] hvm_mmio_internal+0x37/0x67 > > (XEN)[] __hvm_copy+0xe9/0x37d > > (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 > > (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 > > (XEN)[] hvm_io_intercept+0x35/0x5b > > (XEN)[] hvmemul_do_io+0x1ff/0x2c1 > > (XEN)[] hvmemul_do_io_addr+0x117/0x163 > > (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 > > (XEN)[] hvmemul_rep_movs+0x1ef/0x335 > > (XEN)[] x86_emulate+0x56c9/0x13088 > > (XEN)[] _hvm_emulate_one+0x186/0x281 > > (XEN)[] hvm_emulate_one+0x10/0x12 > > (XEN)[] handle_mmio+0x54/0xd2 > > (XEN)[] handle_mmio_with_translation+0x44/0x46 > > (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 > > (XEN)[] vmx_vmexit_handler+0x150e/0x188d > > (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 > > (XEN) > > (XEN) > > (XEN) > > (XEN) Panic on CPU 7: > > (XEN) FATAL TRAP: vector = 2 (nmi) > > (XEN) [error_code=] > > (XEN) > > > > At first I thought it was caused by V5 of the vm_event-based > > introspection series, but I've rolled it back enough to apply V4 on top > > of it (which has been thoroughly tested on Thursday), and it still > > happens, so this would at least appear to be unrelated at this point > > (other than the fact that our use case is maybe somewhat unusual with > > heavy emulation). > > > > I'll keep digging, but since this is a busy time for Xen I thought I'd > > issue a heads-up here as soon as possible, in case the problem is > > obvious for somebody and it helps getting it fixed sooner. > > In c/s 3bbaaec09b1b942f5624dee176da6e416d31f982 there is now a
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 07/13/2015 11:10 AM, Andrew Cooper wrote: > On 13/07/2015 08:48, Razvan Cojocaru wrote: >> Hello, >> >> I'm battling the following hypervisor crash with current staging: >> >> (d2) Invoking ROMBIOS ... >> (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes >> (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ >> (XEN) Watchdog timer detects that CPU7 is stuck! >> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] >> (XEN) CPU:7 >> (XEN) RIP:e008:[] _spin_lock+0x31/0x54 >> (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) >> (XEN) rax: c11d rbx: 83041e687970 rcx: c11e >> (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 >> (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: >> (XEN) r9: r10: 82d08028c3c0 r11: >> (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 >> (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 >> (XEN) cr3: 0004054a cr2: >> (XEN) ds: es: fs: gs: ss: cs: e008 >> (XEN) Xen stack trace from rsp=83040eb37200: >> (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 >> (XEN)0008 830403791bf0 83041e687000 83040eb37268 >> (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 >> (XEN)00c2 83040eb37298 82d0801cb410 000c253f >> (XEN) 00010001 0100 83040eb37328 >> (XEN)82d0801c2403 83040eb37394 83040eb3 >> (XEN)83040eb37360 00c2 8304054cb000 053f >> (XEN)0002 83040eb373f4 00c2 >> (XEN)83040eb373d8 82d08028c620 >> (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 >> (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 >> (XEN)83041e687000 83040eb37398 830403791bf0 0001 >> (XEN)83040eb373d8 0001 000c253f 83040eb373c8 >> (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 >> (XEN) 83040eb37428 82d0801bb440 000a0001 >> (XEN)000c253f 00010001 0111 83040eb37478 >> (XEN)0001 0001 >> (XEN)0001 83040eb374a8 82d0801bc0b9 0001 >> (XEN)000c253f 8300d85fc000 000a0001 0100 >> (XEN)83040eb37728 82e00819dc60 83040eb374c8 >> (XEN) Xen call trace: >> (XEN)[] _spin_lock+0x31/0x54 >> (XEN)[] stdvga_mem_accept+0x3b/0x125 >> (XEN)[] hvm_find_io_handler+0x68/0x8a >> (XEN)[] hvm_mmio_internal+0x37/0x67 >> (XEN)[] __hvm_copy+0xe9/0x37d >> (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 >> (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 >> (XEN)[] hvm_io_intercept+0x35/0x5b >> (XEN)[] hvmemul_do_io+0x1ff/0x2c1 >> (XEN)[] hvmemul_do_io_addr+0x117/0x163 >> (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 >> (XEN)[] hvmemul_rep_movs+0x1ef/0x335 >> (XEN)[] x86_emulate+0x56c9/0x13088 >> (XEN)[] _hvm_emulate_one+0x186/0x281 >> (XEN)[] hvm_emulate_one+0x10/0x12 >> (XEN)[] handle_mmio+0x54/0xd2 >> (XEN)[] handle_mmio_with_translation+0x44/0x46 >> (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 >> (XEN)[] vmx_vmexit_handler+0x150e/0x188d >> (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 >> (XEN) >> (XEN) >> (XEN) >> (XEN) Panic on CPU 7: >> (XEN) FATAL TRAP: vector = 2 (nmi) >> (XEN) [error_code=] >> (XEN) >> >> At first I thought it was caused by V5 of the vm_event-based >> introspection series, but I've rolled it back enough to apply V4 on top >> of it (which has been thoroughly tested on Thursday), and it still >> happens, so this would at least appear to be unrelated at this point >> (other than the fact that our use case is maybe somewhat unusual with >> heavy emulation). >> >> I'll keep digging, but since this is a busy time for Xen I thought I'd >> issue a heads-up here as soon as possible, in case the problem is >> obvious for somebody and it helps getting it fixed sooner. > > In c/s 3bbaaec09b1b942f5624dee176da6e416d31f982 there is now a > deliberate split between stdvga_mem_accept() and stdvga_mem_complete() > about locking and unlocking the stdvga lock. > > At a guess, the previous chain of execution accidentally omitted the > stdvga_mem_complete() call. Thanks, I've reverted that patch and the crash is gone. I'll be happy to test a fix if one is provided, but I don't know enough about that code to go mes
Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
On 13/07/2015 08:48, Razvan Cojocaru wrote: > Hello, > > I'm battling the following hypervisor crash with current staging: > > (d2) Invoking ROMBIOS ... > (XEN) stdvga.c:147:d2v0 entering stdvga and caching modes > (d2) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $ > (XEN) Watchdog timer detects that CPU7 is stuck! > (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:7 > (XEN) RIP:e008:[] _spin_lock+0x31/0x54 > (XEN) RFLAGS: 0202 CONTEXT: hypervisor (d2v0) > (XEN) rax: c11d rbx: 83041e687970 rcx: c11e > (XEN) rdx: 83041e687970 rsi: c11e rdi: 83041e687978 > (XEN) rbp: 83040eb37208 rsp: 83040eb37200 r8: > (XEN) r9: r10: 82d08028c3c0 r11: > (XEN) r12: 83041e687000 r13: 83041e687970 r14: 83040eb37278 > (XEN) r15: 000c253f cr0: 8005003b cr4: 001526e0 > (XEN) cr3: 0004054a cr2: > (XEN) ds: es: fs: gs: ss: cs: e008 > (XEN) Xen stack trace from rsp=83040eb37200: > (XEN)83040eb37278 83040eb37238 82d0801d09b6 0282 > (XEN)0008 830403791bf0 83041e687000 83040eb37268 > (XEN)82d0801cb23a 000c253f 8300d85fc000 0001 > (XEN)00c2 83040eb37298 82d0801cb410 000c253f > (XEN) 00010001 0100 83040eb37328 > (XEN)82d0801c2403 83040eb37394 83040eb3 > (XEN)83040eb37360 00c2 8304054cb000 053f > (XEN)0002 83040eb373f4 00c2 > (XEN)83040eb373d8 82d08028c620 > (XEN) 83040eb37338 82d0801c3e5d 83040eb37398 > (XEN)82d0801cb107 00010eb37394 830403791bf0 830403791bf0 > (XEN)83041e687000 83040eb37398 830403791bf0 0001 > (XEN)83040eb373d8 0001 000c253f 83040eb373c8 > (XEN)82d0801cb291 83040eb37b30 8300d85fc000 0001 > (XEN) 83040eb37428 82d0801bb440 000a0001 > (XEN)000c253f 00010001 0111 83040eb37478 > (XEN)0001 0001 > (XEN)0001 83040eb374a8 82d0801bc0b9 0001 > (XEN)000c253f 8300d85fc000 000a0001 0100 > (XEN)83040eb37728 82e00819dc60 83040eb374c8 > (XEN) Xen call trace: > (XEN)[] _spin_lock+0x31/0x54 > (XEN)[] stdvga_mem_accept+0x3b/0x125 > (XEN)[] hvm_find_io_handler+0x68/0x8a > (XEN)[] hvm_mmio_internal+0x37/0x67 > (XEN)[] __hvm_copy+0xe9/0x37d > (XEN)[] hvm_copy_from_guest_phys+0x14/0x16 > (XEN)[] hvm_process_io_intercept+0x10b/0x1d6 > (XEN)[] hvm_io_intercept+0x35/0x5b > (XEN)[] hvmemul_do_io+0x1ff/0x2c1 > (XEN)[] hvmemul_do_io_addr+0x117/0x163 > (XEN)[] hvmemul_do_mmio_addr+0x24/0x26 > (XEN)[] hvmemul_rep_movs+0x1ef/0x335 > (XEN)[] x86_emulate+0x56c9/0x13088 > (XEN)[] _hvm_emulate_one+0x186/0x281 > (XEN)[] hvm_emulate_one+0x10/0x12 > (XEN)[] handle_mmio+0x54/0xd2 > (XEN)[] handle_mmio_with_translation+0x44/0x46 > (XEN)[] hvm_hap_nested_page_fault+0x15f/0x589 > (XEN)[] vmx_vmexit_handler+0x150e/0x188d > (XEN)[] vmx_asm_vmexit_handler+0x41/0xc0 > (XEN) > (XEN) > (XEN) > (XEN) Panic on CPU 7: > (XEN) FATAL TRAP: vector = 2 (nmi) > (XEN) [error_code=] > (XEN) > > At first I thought it was caused by V5 of the vm_event-based > introspection series, but I've rolled it back enough to apply V4 on top > of it (which has been thoroughly tested on Thursday), and it still > happens, so this would at least appear to be unrelated at this point > (other than the fact that our use case is maybe somewhat unusual with > heavy emulation). > > I'll keep digging, but since this is a busy time for Xen I thought I'd > issue a heads-up here as soon as possible, in case the problem is > obvious for somebody and it helps getting it fixed sooner. In c/s 3bbaaec09b1b942f5624dee176da6e416d31f982 there is now a deliberate split between stdvga_mem_accept() and stdvga_mem_complete() about locking and unlocking the stdvga lock. At a guess, the previous chain of execution accidentally omitted the stdvga_mem_complete() call. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
