From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: irq_guest_eoi_timer interaction with MSI Date: Thu, 13 Nov 2008 09:42:59 +0000 Message-ID: References: <491BFFED.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <491BFFED.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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" 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@lists.xensource.com > http://lists.xensource.com/xen-devel