This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH][RFC] Change edge-interrupt handling in Xen

To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH][RFC] Change edge-interrupt handling in Xen
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 10 Apr 2008 11:22:08 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 10 Apr 2008 03:23:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <823A93EED437D048963A3697DB0E35DE01427E5F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acia76hNUGSt2lAOQ5OWBT2/eag8FwABRKwk
Thread-topic: [PATCH][RFC] Change edge-interrupt handling in Xen
User-agent: Microsoft-Entourage/
On 10/4/08 10:45, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:

We solve the problem in this way:
Move pirq_needs_eoi from dom0's owe memory to share page.
Xen will chage the bit in pirq_needs_eoi dynamically.
Xen uses pending status to judge whether the first one is handled.
On receiving EOI hypercall from guest, unmask the interrupt.

Do you think this approach is viable?

It breaks the existing guest interface and I think it’s probably unnecessary. Unmask the interrupt on a one-millisecond timer. That suitably limits interrupt storms and should guarantee the system makes progress. If we are taking this path very often then we have a very odd system. Perhaps log something via printk() if we take the path frequently (for some arbitrary definition of ‘frequently’)?

Remember that right now we have no storm handling for edge-triggered interrupts and we have no problems so far. The only problem we’ve ever seen is with MSI and an e1000 NIC, at start of day only, and even that can’t be repro’ed reliably.

 -- Keir
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>