On 23/9/08 11:34, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> Simply removing the BUG_ON() seems inappropriate, though. But I'm
> uncertain whether it would be reasonable to call pirq_guest_unbind()
> instead of the BUG_ON(), and if so, how to properly deal with
> irq_desc[vector].lock (the immediate idea would be to factor out the
> locking into a wrapper function, but an alternative would be to use
> recursive locks, and perhaps there are other possibilities).
Well, this hypercall doesn't do pirq_guest_unbind() on IO-APIC-routed
interrupts either, so I think the problem is wider ranging than just MSI
interrupts. Consider unmap_irq() followed by pirq_guest_unbind() later.
We'll BUG_ON(vector == 0) in the latter function. Looks a bit of a mess to
me. I would say that if there are bindings remaining we should re-direct the
event-channel to a 'no-op' pirq (e.g., -1) and indeed call
pirq_guest_unbind() or similar.
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel