From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v9 12/12] xen/arm: gic_events_need_delivery and irq priorities Date: Wed, 18 Jun 2014 13:59:52 +0100 Message-ID: <53A18D48.4000102@linaro.org> References: <1402409240-28114-12-git-send-email-stefano.stabellini@eu.citrix.com> <1403087805.14448.9.camel@kazak.uk.xensource.com> <53A17C69.80306@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com, Ian Campbell List-Id: xen-devel@lists.xenproject.org On 06/18/2014 01:51 PM, Stefano Stabellini wrote: > On Wed, 18 Jun 2014, Julien Grall wrote: >> On 06/18/2014 11:36 AM, Ian Campbell wrote: >>> AIUI there is no relationship here with "xen/arm: make accesses to >>> desc->status flags atomic" which fixes an issue which already present >>> before this series. >> >> The error was not really there before. We were "safe" because the flags >> were cleared before EOIing the IRQ. >> >> Here, we are clearing after EOIing (it has been made by the guest). So >> this race condition can happen more often. > > However considering that when IRQ_GUEST is set, IRQ_INPROGRESS is only > read by irq.c, I think the window for errors is extremely small. > > That doesn't mean we should expose ourselves to risks, so I still > recommend we apply "make accesses to desc->status flags atomic". FYI, with my upcoming device passthrough series, I rely of IRQ_INPROGRESS in release_irq to know if we need to EOI an IRQ routed to the guest. So this series is definitely necessary, otherwise we loose the interrupt for ever. Regards, -- Julien Grall