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

[Radim Krčmář]

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ář <address@hidden>
> > ---
> >  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.  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.