[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice



On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@xxxxxxxxxxx> wrote:

> I have a testing intel machine with 4 physical cpus running 64 bit Xen
> 4.1.3-rc1.
> 
> I have a particular linux VM for which at its kernel boot time ( as
> domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> XEN compiled in.
> 
> Trying to find where the problem is, I found this: at the point where
> XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
> idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
> indefinitely in the

Thanks, the offending patch is xen-unstable:22409, I think. It needs an HVM
guest which maps emulated IRQs onto event channels, but then has event
channel notifications mapped onto an emulated IRQ (rather than 'direct
vector delivery'). An unlikely state of affairs, maybe it's a temporary
setup during guest boot, or maybe it indicates a bug in the guest as well.

In any case, cc'ing the author, Stefano. This ought to be easy to fix. We
could make the irq_lock a recursive lock for example.

 -- Keir

> d->arch.hvm_domain.irq_lock
> 
> ( where "d" is the domain of my domU )
> 
> This is the Xen call trace of the cpu 3, at the point where it spins forever:
> 
> (XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
> (XEN)    [<ffff82c4801d0814>] hvm_set_callback_irq_level+0x34/0x150
> (XEN)    [<ffff82c4801d1245>] hvm_assert_evtchn_irq+0x65/0x90
> (XEN)    [<ffff82c48016e505>] vcpu_mark_events_pending+0x35/0x40
> (XEN)    [<ffff82c4801073f5>] evtchn_set_pending+0x135/0x1c0
> (XEN)    [<ffff82c4801075e7>] send_guest_pirq+0x57/0x70
> (XEN)    [<ffff82c4801d04cb>] assert_gsi+0x5b/0x60
> (XEN)    [<ffff82c4801d07bb>] hvm_isa_irq_assert+0x9b/0xc0
> (XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
> (XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107
> 
> 
> A history of acquiring d->arch.hvm_domain.irq_lock shows that cpu 3
> tries to acquire the same lock twice
> 
> first here:
> 
> (XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
> (XEN)    [<ffff82c4801d0762>] hvm_isa_irq_assert+0x42/0xc0
> (XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
> (XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107
> 
> 
> at hvm_isa_irq_assert()
> 
> and then next at hvm_set_callback_irq_level()
> 
> and it thus spins indefinitely.  Also, the vcpu 0 of Dom0 is bound to
> cpu 3 at that time.
> 
> I am not familiar with XEN internals so I don't know the best way to
> create a patch for fixing this. That's why I am posting this to the
> xen developers list.
> 
> All the best,
> Paulian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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