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


[Xen-devel] spurious interrupts

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] spurious interrupts
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 12 Apr 2006 15:37:00 +0200
Delivery-date: Wed, 12 Apr 2006 06:37:11 -0700
Envelope-to: www-data@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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
While I haven't heard anything whether others were able to reproduce this, I 
was now able to nail this down to a simple
operation: On the system I'm testing with I was able to identify that the 
handling of the interrupt from the SCSI
controller triggers a simultaneous interrupt from one of the USB controllers, 
of which (by way of looking at the native
execution) it is known that it doesn't generate any interrupts. Hence it was 
possible to BUG() the box the first time
such an interrupt appears. This happens when mask_and_ack_level_ioapic_irq() 
masks the irq from the first SCSI
controller (pin 0 of IOAPIC 3). No matter how large delays I insert before 
calling mask_IO_APIC_irq(), the other
interrupt (pin 16 of IOAPIC 0) becomes visible (in the redirection table's irr 
bit) immediately after the write that
sets the mask bit for the first interrupt.

Obviously I am lost here - I have no way to tell why writing on IOAPIC's redir 
entry affects an interrupt routed
through a completely different IOAPIC. Nevertheless it is clear that the 
problem is unique to Xen, because native Linux
doesn't try to mask the IRQ.

Besides the massive spurious interrupts that lead to IRQs getting shut off I'm 
also seeing occasional ones on other
interrupt lines, which must have a different reason. I wonder whether this is 
related to attempts to do irq balancing
(which doesn't seem to work at all under Xen - all device interrupts are always 
seen bound to vcpu 0).

While looking at all this, I also found that CONFIG_PCI_MSI not being supported 
under Xen is a significant limitation,
as some PCI Express devices may not work at all without this (on the box I'm 
working with, all bridges supporting
hotplug). Are there any plans to get this working?

Further, while this also may be a native Linux problem, I wonder whether it is 
appropriate for assign_irq_vector to not
use any serialization regardless of the fact that it accesses static variables 
(in the xenlinux case, the static
current_vector can actually be easily converted into an automatic variable).

Finally, sufficiently unrelated, I wonder whether 
xen_create_contiguous_region() (or its caller(s)) shouldn't special
case order being zero, as it seems pointless to go through numerous hypercalls 
in that case.

Thanks for any comments/explanations, Jan

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>