[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL

On 07/05/2012 15:50, Jan Beulich wrote:
>>>> On 07.05.12 at 16:41, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.