|
xen-devel
Re: [Xen-devel] [PATCH] xen: do not unmask disabled IRQ on eoi.
On Mon, 18 Oct 2010, Jan Beulich wrote:
> >>> 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.
>
If I understand the situation correctly all depends on the ack_type
of the pirq: if it is ACKTYPE_NONE then xen acks the machine irq right
away so there is a possibility of receiving another evtchn while we are
handling the first one.
In this case my patch makes the situation a little worse: previously we
were able to receive a single notification while the evtchn is being
handled while now none.
The other type of pirqs are the ones that have ack_type != ACKTYPE_NONE,
in these cases xen waits for the guest to issue the eoi before acking
the machine irq so it shouldn't be possible to receive any pirqs while
we are handling the first one.
That said, I don't see any simple way to improve this patch so that we
are able to receive one notification while handling a pirq without
changing the semantic of the fasteoi handler or switching to the edge
handler for pirqs that don't need eoi.
> > 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).
>
I think two indirect calls is not too bad, I just need to add a mask_ack
implementation.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home