[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |