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).

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/31429