Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseofits correspondingioapic->irr bit always set

[Jason Wang <jasowang@redhat.com>]

On 08/27/2014 05:31 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?
> Some scenarios, not constant and 100% reproducity, 
> e.g., reboot vm, ifdown e1000 nic, install kaspersky(network configuration is performed during installing stage), .etc.

If you want to start the debugging, I suggest to enable e1000 debug and
then analysis the log before the interrupt storm. This may help to
locate the issue.

Thanks