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: Thu, 23 Oct 2008 10:11:37 +0200 Message-ID: <490031B9.5080604@siemens.com> References: <48FC4671.90409@siemens.com> <48FF493F.6050303@siemens.com> <48FF90C0.3030001@web.de> <200810230951.33997.sheng.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Avi Kivity , kvm-devel To: "Yang, Sheng" Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:17859 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751059AbYJWIMe (ORCPT ); Thu, 23 Oct 2008 04:12:34 -0400 In-Reply-To: <200810230951.33997.sheng.yang@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Yang, Sheng wrote: > On Thursday 23 October 2008 04:44:48 Jan Kiszka wrote: >> 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 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. >> 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). > > Confirmed that "-cpu pentium" solve the problem. But... > > Sorry for that I've found that I neglected some info on the spec. SDM 3B > 5.3.1 "External Interrupts". > > "When the local APIC is global/hardware disabled, these pins are configured as > INTR and NMI pins, respectively." Ah, that's the short-path... > > So, it's right to inject PIC interrupt when LAPIC is hardware disabled. I > think we can drop this patch... > > (I will be more careful on such kind of issues next time...) Well, first of all, I brought this up. Sorry for all the fuss. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux