From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: x86: Don't deliver PIC interrupts to disabled APICs - v2 Date: Wed, 22 Oct 2008 22:44:48 +0200 Message-ID: <48FF90C0.3030001@web.de> References: <48FC4671.90409@siemens.com> <48FC7435.4020707@siemens.com> <48FF33C9.40106@redhat.com> <48FF4235.6020908@siemens.com> <48FF42CE.5070503@siemens.com> <48FF493F.6050303@siemens.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE9A390811A6F0541CE7FFB44" Cc: kvm-devel , "Yang, Sheng" , Jan Kiszka To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:35674 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752144AbYJVUo7 (ORCPT ); Wed, 22 Oct 2008 16:44:59 -0400 In-Reply-To: <48FF493F.6050303@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9A390811A6F0541CE7FFB44 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Avi Kivity wrote: >>>> Jan Kiszka wrote: >>>>> [ taking Sheng's comments into account ] >>>>> >>>>> The logic of kvm_apic_accept_pic_intr has a minor, practically hard= ly >>>>> relevant incorrectness: PIC interrupts are still delivered even if = the >>>>> APIC of VPU0 (BSP) is disabled. This does not comply with the Virtu= al >>>>> Wire mode according to the Intel MP spec. >>>>> =20 >>>> This breaks Windows XP with the Standard PC HAL, so I am unapplying = this >>>> patch. >>> Hmm, this points to either an APIC setup or BIOS bug. To my >>> understanding, the Standard PC HAL should not fiddle with the APIC, s= o >>> what the BIOS leaves behind should counts. But I think I found no tra= ces >>> of APIC manipulation in rombios32.c. >> Manipulation on UP systems. There is fiddling for SMP. But I will chec= k >> again. >=20 > I take everything back: For yet unknown reasons Windows' standard HAL > actually decides to disable the APIC actively. Either there is a > short-path around a disabled APIC for Virtual Wire mode in Real Live > (though I fail to read this out of the spec), or Windows simply has a > bug here (MS insists on NOT supporting the Standard HAL on APIC systems= > [1] - precisely the setup KVM is providing). Sheng, any comments on > this? Guess we have to live with the previous version, maybe with some > refactoring + commenting. I was curious and played with my corresponding qemu patch [1]: It works with the same Windows image that hangs under KVM. Then I looked at a prominent guest-visible difference: the reported CPU type. QEMU claims to provide a CPU called "qemu64" by default. Changing this to Pentium2 or newer makes Windows issue the lethal APIC disable command. On the other hand, calling kvm with "-cpu pentium" makes Windows boot again. However, I still can't tell from this if we see a Windows bug or if the change is incorrect (but me feeling tends to the former). Jan [1] http://permalink.gmane.org/gmane.comp.emulators.qemu/31429 --------------enigE9A390811A6F0541CE7FFB44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkj/kMgACgkQniDOoMHTA+nleQCeJVW9OvuVadFYNE0JQWdmJSE8 58gAnjZBsyCVrboFjJr0hJTq/7SivJFs =/wgU -----END PGP SIGNATURE----- --------------enigE9A390811A6F0541CE7FFB44--