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.

To: Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen: do not unmask disabled IRQ on eoi.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 18 Oct 2010 21:04:43 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "jeremy@xxxxxxxx" <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Mon, 18 Oct 2010 13:06:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1010181754180.2423@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1287139966-19391-2-git-send-email-ian.campbell@xxxxxxxxxx> <alpine.DEB.2.00.1010151614420.2423@kaball-desktop> <1287160335.2003.7973.camel@xxxxxxxxxxxxxxxxxxxxxx> <1287160787.2003.7979.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1010151757240.2423@kaball-desktop> <4CBC1CF1020000780001DA3F@xxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1010181530200.2423@kaball-desktop> <4CBC80E6020000780001DC78@xxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1010181754180.2423@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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

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

Xen-devel mailing list

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