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 17:39:43 +0200 Message-ID: <48FF493F.6050303@siemens.com> References: <48FC4671.90409@siemens.com> <48FC7435.4020707@siemens.com> <48FF33C9.40106@redhat.com> <48FF4235.6020908@siemens.com> <48FF42CE.5070503@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm-devel , "Yang, Sheng" To: Avi Kivity Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:21649 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752616AbYJVPkG (ORCPT ); Wed, 22 Oct 2008 11:40:06 -0400 In-Reply-To: <48FF42CE.5070503@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 hardly >>>> relevant incorrectness: PIC interrupts are still delivered even if the >>>> APIC of VPU0 (BSP) is disabled. This does not comply with the Virtual >>>> Wire mode according to the Intel MP spec. >>>> >>> 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, so >> what the BIOS leaves behind should counts. But I think I found no traces >> of APIC manipulation in rombios32.c. > > Manipulation on UP systems. There is fiddling for SMP. But I will check > again. 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. Jan [1] http://support.microsoft.com/kb/309283/en -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux