[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: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang |
Date: |
Tue, 24 Feb 2015 11:46:06 +0000 |
On Tue, Feb 24, 2015 at 11:35 AM, Stefan Hajnoczi <address@hidden> wrote:
> On Thu, Feb 19, 2015 at 08:24:19PM +0100, 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 ...
>>
>> hw/net/e1000.c | 29 ++++++++++++++++++++++-------
>> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> Hi Alex,
> I've CCed you in case you have any advice regarding QEMU's e1000
> emulation. It seems Windows 8 gets itself into a kind of interrupt
> storm and a workaround in QEMU will be necessary.
>
> Any thoughts?
Okay, I guess Alex has changed jobs since the email has bounced. Too
bad, it was worth a shot.
Regarding the workaround, I'm okay with it. It's a hack for sure but
what other option do we have?
Stefan
Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang, Stefan Hajnoczi, 2015/02/24
- Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang,
Stefan Hajnoczi <=