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

["Zhang Haoyu" <zhanghy@sangfor.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. 

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