Re: [Xen-devel] [PATCH] xen: do not unmask disabled IRQ on eoi.

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 18.10.10 at 16:58, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> 
>>> wrote:
> On Mon, 18 Oct 2010, Jan Beulich wrote:
>> Second, clearing the event channel in the .eoi handler
>> after it wasn't masked while being handled has the potential of
>> losing an event (if it got raised between the IRQ handler checking
>> relevant state and the execution of clear_evtchn()).
> 
> This is only true for virqs because xen knows how to handle the case
> when a pirq is already inflight.

I don't think Xen knowing how to deal with that matters here. It
won't send you a new notification if you would have got one
before clearing the previous instance (and you didn't get another
just because it was already/still pending). Or else I must be missing
something.

> Considering that this is the way the fasteoi handler is supposed to work
> (no ack at the beginning, only at the end) I would keep fasteoi as pirq
> handler and switch virqs to edge.
> If you look at handle_edge_irq, the ack is always done at the beginning,
> no eoi at the end but we don't need it for virqs. Mask and unmask are
> done by the handler depending upon IRQ_INPROGRESS and IRQ_DISABLED.
> It seems exactly the kind of thing we need as virq handler: we clear the
> evtchn in ack and we mask and unmask the evtchn in mask and unmask.
> The mapping of xen operations on the irq chip functions is very simple
> and natural this way.

While that all makes sense, one of the reasons to switch to fasteoi
is because they get along with just a single indirect call. Edge one,
the way you coded it, require three (which can be reduced to two
when using the .mask_ack vector).

Jan


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