From mboxrd@z Thu Jan 1 00:00:00 1970 From: "=?utf-8?B?WmhhbmcgSGFveXU=?=" Subject: =?utf-8?B?UmU6IFtxdWVzdGlvbl0gZTEwMDAgaW50ZXJydXB0IHN0b3JtIGhhcHBlbmVkIGJlY2F1c2VvZiBpdHMgY29ycmVzcG9uZGluZ2lvYXBpYy0+aXJyIGJpdCBhbHdheXMgc2V0?= Date: Mon, 25 Aug 2014 16:27:16 +0800 Message-ID: <201408251627141961019@sangfor.com> References: <201408231836387399956@sangfor.com>, <53FAA874.70703@redhat.com>, <201408251517235889695@sangfor.com>, <53FAE5EB.8080809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "=?utf-8?B?SmFzb24gV2FuZw==?=" , "=?utf-8?B?cWVtdS1kZXZlbA==?=" , "=?utf-8?B?a3Zt?=" Return-path: Received: from smtp.sanfor.com ([58.251.49.30]:34488 "EHLO mail.sangfor.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753958AbaHYI3g (ORCPT ); Mon, 25 Aug 2014 04:29:36 -0400 Sender: kvm-owner@vger.kernel.org List-ID: >>>> 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. We support both, virtio-net is the recommended option, with regard to some guest (e.g., windows server 2000), virtio-net is not supported, e1000 is the last option. >> >>> That was probably caused by something wrong in e1000 emulation which >>> causes interrupt to be injected into windows guest before its interrupt >>> handler is registered. And Windows guest does not have a mechanism to >>> detect and disable irq in such condition. >>> >> Sorry, I don't understand, >> I think one interrupt should not been enabled before its handler is successfully registered, >> is it possible that e1000 emulation inject the interrupt before the interrupt is succesfully enabled? >> >> Thanks, >> Zhang Haoyu >> >>> e1000 emulation is far from stable and complete (e.g run e1000 ethtool >>> selftest in linux guest may see lots of errors). It's complicate and >>> subtle (even has undocumented registers and behaviour). You should >>> better consider to use virtio which are more stable and fast in a kvm >>> guest (unless some intel guys are involved to improve e1000 emulation). >>> >>> Thanks >>>> Thanks, >>>> Zhang Haoyu From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLpem-0000xh-QV for qemu-devel@nongnu.org; Mon, 25 Aug 2014 04:29:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XLpeh-0005OC-J8 for qemu-devel@nongnu.org; Mon, 25 Aug 2014 04:29:40 -0400 Received: from [58.251.49.30] (port=51558 helo=mail.sangfor.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLpeg-0005Nx-Rw for qemu-devel@nongnu.org; Mon, 25 Aug 2014 04:29:35 -0400 Date: Mon, 25 Aug 2014 16:27:16 +0800 From: "=?utf-8?B?WmhhbmcgSGFveXU=?=" References: <201408231836387399956@sangfor.com>, <53FAA874.70703@redhat.com>, <201408251517235889695@sangfor.com>, <53FAE5EB.8080809@redhat.com> Message-ID: <201408251627141961019@sangfor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] =?utf-8?q?=5Bquestion=5D_e1000_interrupt_storm_happe?= =?utf-8?q?ned_becauseof_its_correspondingioapic-=3Eirr_bit_always_?= =?utf-8?q?set?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?SmFzb24gV2FuZw==?= , =?utf-8?B?cWVtdS1kZXZlbA==?= , =?utf-8?B?a3Zt?= >>>> 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. We support both, virtio-net is the recommended option, with regard to some guest (e.g., windows server 2000), virtio-net is not supported, e1000 is the last option. >> >>> That was probably caused by something wrong in e1000 emulation which >>> causes interrupt to be injected into windows guest before its interrupt >>> handler is registered. And Windows guest does not have a mechanism to >>> detect and disable irq in such condition. >>> >> Sorry, I don't understand, >> I think one interrupt should not been enabled before its handler is successfully registered, >> is it possible that e1000 emulation inject the interrupt before the interrupt is succesfully enabled? >> >> Thanks, >> Zhang Haoyu >> >>> e1000 emulation is far from stable and complete (e.g run e1000 ethtool >>> selftest in linux guest may see lots of errors). It's complicate and >>> subtle (even has undocumented registers and behaviour). You should >>> better consider to use virtio which are more stable and fast in a kvm >>> guest (unless some intel guys are involved to improve e1000 emulation). >>> >>> Thanks >>>> Thanks, >>>> Zhang Haoyu