Re: domU and dom0 hung with Xen console interrupt binding showing in-flight=1, (---M)

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 18/08/2010 09:47, "Jan Beulich" <JBeulich@novell.com> wrote:

> Yes, that was what I was trying to hint at, but I wasn't sure whether
> calling ->end() here has any unintended side effects and/or requires
> any extra care (like preventing a subsequent guest initiated EOI to
> call ->end() again).

Oh you can't naively call ->end() from the time-out handler. You would need
to do something like this in irq_guest_eoi_timer_fn:
 spin_lock(&desc->lock);
 if ( (desc->status & IRQ_GUEST) &&
      (action->ack_type == ACKTYPE_EOI) ) {
    cpu_eoi_map = action->cpu_eoi_map;
    spin_unlock(&desc->lock);
    on_selected_cpus(&cpu_eoi_map, set_eoi_ready, desc, 0);
    spin_lock(&desc->lock);
 }
 _irq_guest_eoi(desc);
 spin_unlock(&desc->lock);

I don't think the IRQ_GUEST_EOI_PENDING flag or any of that stuff is needed
for the ACKTYPE_EOI case. I'd make the handling of that, calling of
->disable/->enable and so on, dependent on ACKTYPE_NONE.

> While looking at this I came across another thing I don't understand:
> __pirq_guest_eoi(), for the ACKTYPE_EOI case, calls __set_eoi_ready()
> in a cpu_test_and_clear() conditional, but __set_eoi_ready() bails
> out if it finds !cpu_test_and_clear() on the same bitmap - what's the
> point of calling __set_eoi_ready() here then (or what am I missing)?

__pirq_guest_eoi() acts on a private on-stack copy of cpu_eoi_map. This is
because on_selected_cpus() cannot be called with desc->lock held. But as
soon as desc->lock is released, the desc->action structure can be freed by
another CPU, so it would be invalid to reference action->cpu_eoi_map
directly after desc->lock is released.

 -- Keir