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 correspondingioapic->irr bit always set
Date: Wed, 27 Aug 2014 13:09:49 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 08/26/2014 05:28 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?
>
> Thanks,
> Zhang Haoyu
>
>




reply via email to

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