[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 Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |