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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 18 Oct 2010, Stefano Stabellini wrote:
> 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.
> 

Actually it has just occurred to me that we can safely have clear_evtchn in
do_upcall and at the same time not mask the evtchn because we are
protected against executing multiple upcalls at the same time anyway by
xed_nesting_count.

I'll try to respin another patch following with idea.

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