Re: [GIT PULL] Fix lost interrupt race in Xen event channels

["Jan Beulich" <JBeulich@novell.com>]

>>> On 27.08.10 at 22:43, Daniel Stodden <daniel.stodden@citrix.com> wrote:
> So let's come up with a new theory. Right now I'm still
> looking at xen/next. Correct me if I'm mistaken:
> 
> mask_ack_pirq will:
>  1. chip->mask
>  2. chip->ack
> 
> Where chip->ack will:
>  1. move_native_irq
>  2. clear_evtchn.
> 
> Now if you look into move_native_irq, it will:
>  1. chip->mask (gratuitous)
>  2. move
>  3. chip->unmask (aiiiiiie).
> 
> That explains why edge_irq still fixed the problem.

This totals to it having been wrong to break up -mask() and ->ack() -
when using the combined ->mask_ack() (like in XCP etc) it would have
been pretty obvious that move_native_irq() cannot go between
mask() and ack().

For us, using fasteoi, move_native_irq() sits in ->eoi(), before
un-masking. One could, as Jeremy suggests, call move_masked_irq()
here, but I didn't want to duplicate the IRQ_DISABLED check done
in move_native_irq(), mainly to not depend on following potential
future changes (additions) to the set of conditions checked there.

Helpful would be if the function returned whether it actually went
through the mask/unmask pair, as I'm not sure the double
unmasking really is a good idea, especially in the PIRQ case (for
the moment I'm considering putting an already-unmasked check
into both ->eoi() handlers).

Jan