| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI
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
|
|
|
| |
|
Home