WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] irq_guest_eoi_timer interaction with MSI

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] irq_guest_eoi_timer interaction with MSI
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 13 Nov 2008 09:22:37 +0000
Delivery-date: Thu, 13 Nov 2008 01:23:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
While awaiting final confirmation, all aspects of an issue with certain bnx2
driven NICs known at this point suggest that the disabling of MSI when a
second interrupt gets delivered without the first having progressed far
enough in its handling to at least mask the corresponding event channel
would cause the NIC to stop operating. We're being told that it is a chip
limitation that it can't recover from MSI getting disabled and then
re-enabled - it would switch into INTA mode when MSI gets disabled, but
not switch back to MSI mode when MSI gets re-enabled.

While this arguably is a limitation that must be worked around in the driver,
the logic here raises questions: Since other devices apparently have
similar behavior in not disabling IRQ delivery upon IRQ assertion, wouldn't
it to be expected that disabling IRQs for a millisecond could have severe
impact on throughput of the device? Also, is it correct at all to disable MSI
on a device - i.e., with the affected device going into INTA mode, don't
we risk floods of spurious interrupts if the IO-APIC RTE the device is
connected to is shared and happens to be unmasked?

Apart from that - wouldn't the stop_timer() call be carried out more
correctly before calling desc->handler->disable(), so that we can be sure
the disable actually has an effect?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel