[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 13 Nov 2008 09:42:59 +0000
  • Cc:
  • Delivery-date: Thu, 13 Nov 2008 01:43:21 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclFdDaFdQQaMLFnEd2PJwAWy6hiGQ==
  • Thread-topic: [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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.