[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang
From: |
Jason Wang |
Subject: |
Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang |
Date: |
Tue, 31 Mar 2015 13:26:47 +0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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.
- The issue looks similar to the one that has been addressed by kernel
commit 184564efae4d775225c8fe3b762a56956fb1f827. Is this still
reproducible with this commit?
Thanks