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

[Jason Wang <jasowang@redhat.com>]

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.
- The issue looks similar to the one that has been addressed by kernel
commit 184564efae4d775225c8fe3b762a56956fb1f827. Is this still
reproducible with this commit?

Thanks