From: "Zhang Haoyu" <zhanghy@sangfor.com>
To: "Jason Wang" <jasowang@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseofits correspondingioapic->irr bit always set
Date: Wed, 27 Aug 2014 17:31:51 +0800 [thread overview]
Message-ID: <201408271731497879013@sangfor.com> (raw)
In-Reply-To: 53FD681D.7070602@redhat.com
>>>>>> 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?
Some scenarios, not constant and 100% reproducity,
e.g., reboot vm, ifdown e1000 nic, install kaspersky(network configuration is performed during installing stage), .etc.
Thanks,
Zhang Haoyu
>>
>> Thanks,
>> Zhang Haoyu
next prev parent reply other threads:[~2014-08-27 9:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 10:36 [Qemu-devel] [question] e1000 interrupt storm happened because of its corresponding ioapic->irr bit always set Zhang Haoyu
2014-08-25 3:07 ` Jason Wang
2014-08-25 7:17 ` [Qemu-devel] [question] e1000 interrupt storm happened becauseof " Zhang Haoyu
2014-08-25 7:29 ` Jason Wang
2014-08-25 8:27 ` [Qemu-devel] [question] e1000 interrupt storm happened becauseof its correspondingioapic->irr " Zhang Haoyu
2014-08-26 9:28 ` Zhang Haoyu
2014-08-27 5:09 ` Jason Wang
2014-08-27 9:31 ` Zhang Haoyu [this message]
2014-08-28 7:12 ` [Qemu-devel] [question] e1000 interrupt storm happened becauseofits " Jason Wang
2014-08-28 12:55 ` [Qemu-devel] [question] e1000 interrupt storm happenedbecauseofits " Zhang Haoyu
2014-08-29 2:50 ` Jason Wang
2014-08-29 3:14 ` [Qemu-devel] [question] e1000 interrupt storm happenedbecauseofitscorrespondingioapic->irr " Zhang Haoyu
2014-08-29 4:07 ` Zhang, Yang Z
2014-08-29 4:28 ` Jason Wang
2014-09-02 15:44 ` [Qemu-devel] [question] e1000 interrupt storm happenedbecauseofits correspondingioapic->irr " Michael S. Tsirkin
2014-09-04 1:56 ` [Qemu-devel] [question] e1000 interrupt stormhappenedbecauseofits " Zhang Haoyu
2014-09-04 4:57 ` Jason Wang
2014-08-25 7:32 ` [Qemu-devel] [question] e1000 interrupt storm happened becauseof its corresponding ioapic->irr " Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201408271731497879013@sangfor.com \
--to=zhanghy@sangfor.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).