Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang

[Jason Wang <jasowang@redhat.com>]

On Tue, Mar 31, 2015 at 6:17 PM, Radim Krčmář <rkrcmar@redhat.com> 
wrote:
> 2015-03-31 13:26+0800, Jason Wang:
>>  On 02/20/2015 03:24 AM, Radim Krčmář wrote:
>>  > Window 8.0 driver has a particular behavior for a small time 
>> frame after
>>  > it enables rx interrupts:  the interrupt handler never clears
>>  > E1000_ICR_RXT0.  The handler does this something like this:
>>  >   set_imc(-1)               (1) disable all interrupts
>>  >   val = read_icr()          (2) clear ICR
>>  >   handled = magic(val)      (3) do nothing to E1000_ICR_RXT0
>>  >   set_ics(val & ~handled)   (4) set unhandled interrupts back to 
>> ICR
>>  >   set_ims(157)              (5) enable some interrupts
>>  >
>>  > so if we started with RXT0, then every time the handler 
>> re-enables e1000
>>  > interrupts, it receives one.  This likely wouldn't matter in real
>>  > hardware, because it is slow enough to make some progress between
>>  > interrupts, but KVM instantly interrupts it, and boot hangs.
>>  > (If we have multiple VCPUs, the interrupt gets load-balanced and
>>  >  everything is fine.)
>>  >
>>  > I haven't found any problem in earlier phase of initialization and
>>  > windows writes 0 to RADV and RDTR, so some workaround looks like 
>> the
>>  > only way if we want to support win8.0 on uniprocessors.  (I vote 
>> NO.)
>>  >
>>  > This workaround uses the fact that a constant is cleared from ICR 
>> and
>>  > later set back to it.  After detecting this situation, we reuse 
>> the
>>  > mitigation framework to inject an interrupt 10 microseconds later.
>>  > (It's not exactly 10 microseconds, to keep the existing logic 
>> intact.)
>>  >
>>  > The detection is done by checking at (1), (2), and (5).  (2) and 
>> (5)
>>  > require that the only bit in ICR is RXT0.  We could also check at 
>> (4),
>>  > and on writes to any other register, but it would most likely 
>> only add
>>  > more useless code, because normal operations shouldn't behave 
>> like that
>>  > anyway.  (An OS that deliberately keeps bits in ICR to notify 
>> itself
>>  > that there are more packets, or for more creative reasons, is 
>> nothing we
>>  > should care about.)
>>  >
>>  > Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>>  > ---
>>  >  The patch is still untested -- it only approximates the behavior 
>> of RHEL
>>  >  patches that worked, I'll try to get a reproducer ...
>>  
>>  Hi:
>>  
>>  Two questions:
>>  
>>  - Does Win8 still support 82540EM. According to
>>  
>> https://downloadcenter.intel.com/download/23071/Network-Adapter-Driver-for-Windows-8-1-
>>  , it was not in the supported list. As a reference, 82540EM was in 
>> the
>>  list of win2008:
>>  
>> https://downloadcenter.intel.com/download/18720/Network-Adapter-Driver-for-Windows-Server-2008-Final-Release.
>>  If it was not supported officially, there's probably no need to
>>  workaround a buggy driver in guest.
> 
> Probably not:
> http://www.intel.com/support/network/adapter/pro100/sb/CS-033693.htm
> https://downloadcenter.intel.com/download/21642/Network-Adapter-Driver-for-Windows-8-
> 
> That makes things simple, thank you.
> I see no reason to sabotage QEMU with this patch now.
> 
>>  - The issue looks similar to the one that has been addressed by 
>> kernel
>>  commit 184564efae4d775225c8fe3b762a56956fb1f827. Is this still
>>  reproducible with this commit?
> 
> Windows issues EOI between steps (1) and (2), while the line is down, 
> so
> the patch doesn't recognize it as EOI storm. 

I see.

>  It's another problem with
> zero latencies ... we could workaround it in the kernel by remembering
> last interrupts and delaying down the injection a bit if the same one 
> is
> injected too often within some time frame; I wouldn't do that either.

Agree, thanks for the explanation.