From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [xen-unstable test] 11946: regressions - FAIL
Date: Mon, 7 May 2012 16:40:18 +0100
Message-ID: <4FA7ECE2.4080208@citrix.com>
References: <osstest-11946-mainreport@xen.org>
	<1329216291.31256.207.camel@zakaz.uk.xensource.com>
	<1332844592.25560.9.camel@zakaz.uk.xensource.com>
	<CAGU+auvEvjy3qi3d9ZxMyFdHxauGL6wC=out07rxF-0sMfP8jg@mail.gmail.com>
	<4FA437E7.6040105@citrix.com>
	<CAGU+auvu7DzVbRavS74AmNDOb3gS-dVHr3inVJFYZQQVbVMe6Q@mail.gmail.com>
	<4FA79F9F0200007800081F5F@nat28.tlf.novell.com>
	<4FA7B6EF.9030403@citrix.com>
	<4FA7EB80020000780008204B@nat28.tlf.novell.com>
	<4FA7DF2B.3020000@citrix.com>
	<4FA7FD3B02000078000820A3@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <4FA7FD3B02000078000820A3@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>
List-Id: xen-devel@lists.xenproject.org

On 07/05/2012 15:50, Jan Beulich wrote:
>>>> On 07.05.12 at 16:41, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Given that the legacy vectors cant migrate, is it wise including them in
>> the loop in irq_move_cleanup_interrupt()?  In fact, is it wise including
>> any vector above LAST_DYNAMIC_VECTOR?
> Likely not, but then again this is the final piece of moving an interrupt,
> so there must have been something earlier that incorrectly initiated a
> move. In other words, rather than fixing the loop here, we should
> make sure execution can't even make it there for legacy vectors.
>
> And of course this is irrespective of the fact that no legacy interrupt
> should occur in the first place, unless this is a very strange system.
>
> Jan
>

The only way to get to this point is if desc->arch.move_cleanup_count is
non 0, in which case, one of these functions:

hpet_msi_ack (hpet.c)
ack_edge_ioapic_irq (io_apci.c)
mask_and_ack_level_ioapic_irq (io_apic.c)
ack_nonmaskable_msi_irq (msi.c)
iommu_msi_mask (iommu_init.c)
dma_msi_mask (iommu.c)

has called irq_complete_move, after something has called
__assign_irq_vector() to move the irq to another CPU.

I would say something very fishy is going on - no desc used by any of
those functions should have a vector from the legacy region.

As for the loop, it is probably quite sensible to reduce that down to
LAST_DYNAMIC_VECTOR.  Leaving it at NR_VECTORS is just 32 wasted
iterations of the loop in interrupt context.