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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
