From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd7iL-0007yV-5j for qemu-devel@nongnu.org; Tue, 31 Mar 2015 21:45:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yd7iG-0006oo-6N for qemu-devel@nongnu.org; Tue, 31 Mar 2015 21:45:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd7iF-0006oa-V9 for qemu-devel@nongnu.org; Tue, 31 Mar 2015 21:45:00 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t311ixk5023419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 31 Mar 2015 21:44:59 -0400 Date: Wed, 01 Apr 2015 09:44:29 +0800 From: Jason Wang Message-Id: <1427852669.4678.0@smtp.corp.redhat.com> In-Reply-To: <20150331101726.GB14262@potion.brq.redhat.com> References: <1424373859-2019-1-git-send-email-rkrcmar@redhat.com> <551A3017.7030306@redhat.com> <20150331101726.GB14262@potion.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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: Radim =?iso-8859-2?b?S3LobeH4?= Cc: qemu-devel@nongnu.org, Wei Huang On Tue, Mar 31, 2015 at 6:17 PM, Radim Kr=C4=8Dm=C3=A1=C5=99 =20 wrote: > 2015-03-31 13:26+0800, Jason Wang: >> 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=20 >> 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 =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=20 >> ICR >> > set_ims(157) (5) enable some interrupts >> > >> > so if we started with RXT0, then every time the handler=20 >> 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=20 >> the >> > only way if we want to support win8.0 on uniprocessors. (I vote=20 >> NO.) >> > >> > This workaround uses the fact that a constant is cleared from ICR=20 >> and >> > later set back to it. After detecting this situation, we reuse=20 >> the >> > mitigation framework to inject an interrupt 10 microseconds later. >> > (It's not exactly 10 microseconds, to keep the existing logic=20 >> intact.) >> > >> > The detection is done by checking at (1), (2), and (5). (2) and=20 >> (5) >> > require that the only bit in ICR is RXT0. We could also check at=20 >> (4), >> > and on writes to any other register, but it would most likely=20 >> only add >> > more useless code, because normal operations shouldn't behave=20 >> like that >> > anyway. (An OS that deliberately keeps bits in ICR to notify=20 >> itself >> > that there are more packets, or for more creative reasons, is=20 >> nothing we >> > should care about.) >> > >> > Signed-off-by: Radim Kr=C4=8Dm=C3=A1=C5=99 >> > --- >> > The patch is still untested -- it only approximates the behavior=20 >> of RHEL >> > patches that worked, I'll try to get a reproducer ... >> =20 >> Hi: >> =20 >> Two questions: >> =20 >> - Does Win8 still support 82540EM. According to >> =20 >> https://downloadcenter.intel.com/download/23071/Network-Adapter-Driver-f= or-Windows-8-1- >> , it was not in the supported list. As a reference, 82540EM was in=20 >> the >> list of win2008: >> =20 >> https://downloadcenter.intel.com/download/18720/Network-Adapter-Driver-f= or-Windows-Server-2008-Final-Release. >> If it was not supported officially, there's probably no need to >> workaround a buggy driver in guest. >=20 > Probably not: > http://www.intel.com/support/network/adapter/pro100/sb/CS-033693.htm > https://downloadcenter.intel.com/download/21642/Network-Adapter-Driver-fo= r-Windows-8- >=20 > That makes things simple, thank you. > I see no reason to sabotage QEMU with this patch now. >=20 >> - The issue looks similar to the one that has been addressed by=20 >> kernel >> commit 184564efae4d775225c8fe3b762a56956fb1f827. Is this still >> reproducible with this commit? >=20 > Windows issues EOI between steps (1) and (2), while the line is down,=20 > so > the patch doesn't recognize it as EOI storm.=20 I see. > 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=20 > is > injected too often within some time frame; I wouldn't do that either. Agree, thanks for the explanation. =