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] [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

> 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).


Xen-devel mailing list

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