From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: VM hung after running sometime Date: Wed, 29 Sep 2010 09:12:07 -0700 Message-ID: <4CA36557.4040706@goop.org> References: , , <4C98EB42.4020808@goop.org>, , , <4C994B08.7050509@goop.org> , , <4C9A4B7A.3010308@goop.org>, , <4C9BE0A9.40709@goop.org>, , <4CA220D0.7070309@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: MaoXiaoyun Cc: xen devel , keir.fraser@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 09/28/2010 11:01 PM, MaoXiaoyun wrote: > Well=A3=AC I just go throught the source of irqbalance, it shows that i= t > balances the irq through > updating /proc/irq/$irq/smp_affinity. That, in my understanding, set > irq affinity is almost > equal to irq migration. Correct. > > I later find the NIC interrupt is not modified in dom0, so it is safe > to set its affinity, > but interrupt of xen event use handle_level_irq, set its affinity will > subject to irq > lost. > > Am I right? I can't parse that sentence so I'm not sure. But if you have successfully migrated the interrupt/evtchn to a different vcpu, then there's no subsequent risk of lost events. The event loss can only happen in the circumstance I mentioned earlier: when you migrate while an event is being handled, and a second event occurs on the new cpu before the first one has finished. So you need both bad timing and a fairly high event delivery rate to trigger the problem. J