qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its


From: Jason Wang
Subject: Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its corresponding ioapic->irr bit always set
Date: Mon, 25 Aug 2014 15:29:47 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 08/25/2014 03:17 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. 
>
>> 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
>>>
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]