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] [GIT PULL] Fix lost interrupt race in Xen event channel

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [GIT PULL] Fix lost interrupt race in Xen event channels
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 30 Aug 2010 09:36:31 -0700
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Tom Kopec <tek@xxxxxxx>, Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Delivery-date: Mon, 30 Aug 2010 09:37:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C7B81FB0200007800012C16@xxxxxxxxxxxxxxxxxx>
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: <4C743B2C.8070208@xxxxxxxx> <4C74E7C802000078000120C0@xxxxxxxxxxxxxxxxxx> <4C7558E0.1060806@xxxxxxxx> <4C7629D10200007800012387@xxxxxxxxxxxxxxxxxx> <4C769736.4050409@xxxxxxxx> <4C7799EB020000780001276F@xxxxxxxxxxxxxxxxxx> <1282941781.26797.386.camel@xxxxxxxxxxxxxxxxxxxxxxx> <4C7B81FB0200007800012C16@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 On 08/30/2010 01:03 AM, Jan Beulich wrote:
> This totals to it having been wrong to break up -mask() and ->ack() -
> when using the combined ->mask_ack() (like in XCP etc) it would have
> been pretty obvious that move_native_irq() cannot go between
> mask() and ack().

Probably, but I just viewed the mask_ack() as an optimisation that
didn't need to be addressed on the first pass.  I converted the basic
event channels to fasteoi and it seems to work OK.  I'll look at pirq today.

> For us, using fasteoi, move_native_irq() sits in ->eoi(), before
> un-masking. One could, as Jeremy suggests, call move_masked_irq()
> here, but I didn't want to duplicate the IRQ_DISABLED check done
> in move_native_irq(), mainly to not depend on following potential
> future changes (additions) to the set of conditions checked there.

Is there actually a problem with moving a IRQ_DISABLED interrupt?  If
so, shouldn't that IRQ_DISABLED check also be in move_masked_irq()?


Xen-devel mailing list