Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

A perfectly reasonable fix if you are not worried about guest-initiated irq
storms (e.g. because all devices are controlled by dom0) would be to remove
the eoi_timer logic. Otherwise we could relax it some (e.g., require N IRQs
to get stacked up rather than just 1; or add explicit rate limiting).

We only disable MSI when the device does not support masking. Perhaps we
should make disable/enable no-ops in that case?

 -- Keir

On 13/11/08 09:22, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> 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



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