This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

>>> On 27.08.10 at 22:43, Daniel Stodden <daniel.stodden@xxxxxxxxxx> 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).


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>