| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] xen: do not unmask disabled IRQ on eoi.
>>> 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
|
|
|
| |
|
Home