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] x86: clear_IO_APIC_pin() and SMI delivery mode

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] x86: clear_IO_APIC_pin() and SMI delivery mode
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 06 Feb 2008 13:00:08 +0000
Delivery-date: Wed, 06 Feb 2008 05:00:07 -0800
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
clear_IO_APIC_pin() ignores entries that are set to delivery mode SMI.
While this seems reasonable if the entry was unmasked, I consider it
dubious for masked entries.

In Linux, such behavior is benign since when the entry later is being
used for some normal interrupt, the old setting is simply overwritten.
In Xen, however, ioapic_guest_write() uses the vector field to
determine the previous associated IRQ and possibly call
remove_pin_at_irq() - this is where we got a report of a hypervisor
crash - the BUG() in the first loop of this function triggers.

Since I see two ways of fixing this (and perhaps there are more),
before creating a patch I'd like to understand which of the
approaches seems more reasonable (or whether both should be

a) Only ignore un-masked SMI delivery mode entries in

b) Ignore the vector information in ioapic_guest_write() for all
delivery modes (at least in old_rte, new_rte is currently not allowed
to have anything but fixed or lowest priority) that don't allow a


Xen-devel mailing list

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