From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcohW-0002m6-Il for qemu-devel@nongnu.org; Tue, 31 Mar 2015 01:26:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcohR-0006Fu-Ag for qemu-devel@nongnu.org; Tue, 31 Mar 2015 01:26:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40753) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcohR-0006Fj-5p for qemu-devel@nongnu.org; Tue, 31 Mar 2015 01:26:53 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 05BD4350060 for ; Tue, 31 Mar 2015 05:26:51 +0000 (UTC) Message-ID: <551A3017.7030306@redhat.com> Date: Tue, 31 Mar 2015 13:26:47 +0800 From: Jason Wang MIME-Version: 1.0 References: <1424373859-2019-1-git-send-email-rkrcmar@redhat.com> In-Reply-To: <1424373859-2019-1-git-send-email-rkrcmar@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] e1000: work around win 8.0 boot hang List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , qemu-devel@nongnu.org Cc: Wei Huang On 02/20/2015 03:24 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > Window 8.0 driver has a particular behavior for a small time frame afte= r > 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 =3D read_icr() (2) clear ICR > handled =3D 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 e100= 0 > 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 w= e > should care about.) > > Signed-off-by: Radim Kr=C4=8Dm=C3=A1=C5=99 > --- > The patch is still untested -- it only approximates the behavior of RH= EL > 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-fo= r-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-fo= r-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