[Xen-devel] irq_guest_eoi_timer interaction with MSI

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

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