WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] Handle MSI irq storm

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] Handle MSI irq storm
From: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
Date: Thu, 3 Jul 2008 16:56:33 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 03 Jul 2008 01:59:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4924817.1A7BA%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <823A93EED437D048963A3697DB0E35DE017FD97E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4924817.1A7BA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acjcy8F+D4qxw0AnTb6V8UsSMvI8BwAGIrDfAABHUbA=
Thread-topic: [PATCH] Handle MSI irq storm
Hi, Keir,

I will make updates on hvm EOI function.

I don't think that there already was storm-avoidance logic included when the 
final MSI/MSI-X patch sets were checked in, because at that time I could not 
reproduce this strange IRQ storm. And I thought I could not add such logic if 
everything already ran well. But unluckily enough, our QA people are 
experiencing this storm now.

My considerations are in the following description:
Level-triggered interrupts are not in the scope of IRQ storm, so I do not touch 
them at all.
For edge-triggered interrupts, I must first be able to tell which the second 
interrupt is, so I must know when the first interrupt has already been handled. 
For HVM guest, I assume that when EOI (virtual) is written guest has finished 
the interrupt handling (or at least, it has started handling). 
But for non-HVM guest, I have not thought of a good point now. I just assume 
the interrupt has been services as soon as pirq is sent to guest. Do you have 
any suggestions on this?

Shan Haitao

-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
Sent: 2008年7月3日 16:11
To: Shan, Haitao
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH] Handle MSI irq storm

I thought that there already was storm-avoidance logic included, because of
the other storm scenario you used to be able to reproduce? Also this patch
looks like it will only avoid storms destined for an HVM guest. A non-HVM
irq will have IRQ_INPROGRESS cleared before interrupt delivery is
re-enabled. So if a storm does occur, it will look like the previous
interrupt was already handled when it in fact wasn't?

In the hvm EOI function you clear IRQ_INPROGRESS but do not ->enable() the
irq line. Is that correct?

 -- Keir

On 3/7/08 06:15, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:

>  <<handle_msi_irq_storm.patch>> Hi, Keir,
> 
> This patch handles MSI irq storm. Unluckily, I have observed this
> phenomenon again. This will happen when some kind of MSI-X capable NIC
> is assigned to an HVM guest. The basic idea is to mask the interrupt on
> receiving the second interrupt and set a timer to unmask after 1ms.
> Can you have a look and give some comments on that? Thanks!
> 
> Best Regards
> Shan Haitao 



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