From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [question] e1000 interrupt storm happened becauseof its correspondingioapic->irr bit always set Date: Wed, 27 Aug 2014 13:09:49 +0800 Message-ID: <53FD681D.7070602@redhat.com> References: <201408231836387399956@sangfor.com>, <53FAA874.70703@redhat.com>, <201408251517235889695@sangfor.com>, <53FAE5EB.8080809@redhat.com> <201408261728240882530@sangfor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Zhang Haoyu , qemu-devel , kvm Return-path: In-Reply-To: <201408261728240882530@sangfor.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 08/26/2014 05:28 PM, Zhang Haoyu wrote: >>>>> Hi, all >>>>> >>>>> I use a qemu-1.4.1/qemu-2.0.0 to run win7 guest, and encounter e1000 NIC interrupt storm, >>>>> because "if (!ent->fields.mask && (ioapic->irr & (1 << i)))" is always true in __kvm_ioapic_update_eoi(). >>>>> >>>>> Any ideas? >>>> We meet this several times: search the autoneg patches for an example of >>>> workaround for this in qemu, and patch kvm: ioapic: conditionally delay >>>> irq delivery during eoi broadcast for an workaround in kvm (rejected). >>>> >>> Thanks, Jason, >>> I searched "e1000 autoneg" in gmane.comp.emulators.qemu, and found below patches, >>> http://thread.gmane.org/gmane.comp.emulators.qemu/143001/focus=143007 >> This series is the first try to fix the guest hang during guest >> hibernation or driver enable/disable. >>> http://thread.gmane.org/gmane.comp.emulators.qemu/284105/focus=284765 >>> http://thread.gmane.org/gmane.comp.emulators.qemu/186159/focus=187351 >> Those are follow-up that tries to fix the bugs introduced by the autoneg >> hack. >>> which one tries to fix this problem, or all of them? >> As you can see, those kinds of hacking may not as good as we expect >> since we don't know exactly how e1000 works. Only the register function >> description from Intel's manual may not be sufficient. And you can >> search e1000 in the archives and you can find some behaviour of e1000 >> registers were not fictionalized like what spec said. It was really >> suggested to use virtio-net instead of e1000 in guest. > Will the "[PATCH] kvm: ioapic: conditionally delay irq delivery during eoi broadcast" add delay to virtual interrupt injection sometimes, > then some time delay sensitive applications will be impacted? I don't test it too much but it only give a minor delay of 1% irq in the hope of guest irq handler will be registered shortly. But I suspect it's the bug of e1000 who inject the irq in the wrong time. Under what cases did you meet this issue? > > Thanks, > Zhang Haoyu > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMVUg-0000z3-DG for qemu-devel@nongnu.org; Wed, 27 Aug 2014 01:10:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMVUZ-0002RL-1O for qemu-devel@nongnu.org; Wed, 27 Aug 2014 01:10:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMVUY-0002R1-Q6 for qemu-devel@nongnu.org; Wed, 27 Aug 2014 01:09:54 -0400 Message-ID: <53FD681D.7070602@redhat.com> Date: Wed, 27 Aug 2014 13:09:49 +0800 From: Jason Wang MIME-Version: 1.0 References: <201408231836387399956@sangfor.com>, <53FAA874.70703@redhat.com>, <201408251517235889695@sangfor.com>, <53FAE5EB.8080809@redhat.com> <201408261728240882530@sangfor.com> In-Reply-To: <201408261728240882530@sangfor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its correspondingioapic->irr bit always set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Haoyu , qemu-devel , kvm On 08/26/2014 05:28 PM, Zhang Haoyu wrote: >>>>> Hi, all >>>>> >>>>> I use a qemu-1.4.1/qemu-2.0.0 to run win7 guest, and encounter e1000 NIC interrupt storm, >>>>> because "if (!ent->fields.mask && (ioapic->irr & (1 << i)))" is always true in __kvm_ioapic_update_eoi(). >>>>> >>>>> Any ideas? >>>> We meet this several times: search the autoneg patches for an example of >>>> workaround for this in qemu, and patch kvm: ioapic: conditionally delay >>>> irq delivery during eoi broadcast for an workaround in kvm (rejected). >>>> >>> Thanks, Jason, >>> I searched "e1000 autoneg" in gmane.comp.emulators.qemu, and found below patches, >>> http://thread.gmane.org/gmane.comp.emulators.qemu/143001/focus=143007 >> This series is the first try to fix the guest hang during guest >> hibernation or driver enable/disable. >>> http://thread.gmane.org/gmane.comp.emulators.qemu/284105/focus=284765 >>> http://thread.gmane.org/gmane.comp.emulators.qemu/186159/focus=187351 >> Those are follow-up that tries to fix the bugs introduced by the autoneg >> hack. >>> which one tries to fix this problem, or all of them? >> As you can see, those kinds of hacking may not as good as we expect >> since we don't know exactly how e1000 works. Only the register function >> description from Intel's manual may not be sufficient. And you can >> search e1000 in the archives and you can find some behaviour of e1000 >> registers were not fictionalized like what spec said. It was really >> suggested to use virtio-net instead of e1000 in guest. > Will the "[PATCH] kvm: ioapic: conditionally delay irq delivery during eoi broadcast" add delay to virtual interrupt injection sometimes, > then some time delay sensitive applications will be impacted? I don't test it too much but it only give a minor delay of 1% irq in the hope of guest irq handler will be registered shortly. But I suspect it's the bug of e1000 who inject the irq in the wrong time. Under what cases did you meet this issue? > > Thanks, > Zhang Haoyu > >