Re: [Qemu-devel] winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-12-06 17:29, Michael Tokarev wrote:
> [Added Jan Kiszka to Cc]
> 
> On 06.12.2011 18:45, Michael Tokarev wrote:
> [complete thread: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705]
> 
>> More data points (all against qemu-kvm-0.15.0).
>>
>> First, as Avi pointed out, this patch references PIC which is
>> used by standardPC HAL and not used by ACPI HAL.  So it might
>> be something to think about, at least.
>>
>> Now, so far, all deviecs which are on IRQ11 are affected.  When
>> enabling USB and NIC, they both gets assigned to IRQ11 and both
>> does not work.  When enabling just one of them (either), only
>> that device (which gets assigned to IRQ11) does not work.  All
>> other devices apparently works fine (including PS/2 Mouse on
>> IRQ12).
>>
>> When using just one of NIC/USB, all IRQs in the guest becomes
>> single-device, so IRQ sharing isn't a problem.
>>
>> I wasn't able to force the guest to use IRQ10 so far (to verify).
>>
>> Also, when booted with -no-kvm-irqchip, guest Just Works, including
>> USB and NIC sharing IRQ11.
>>
>> While on IRC there was one more person who suffered from the same
>> issue, now with Win2003.  He was able to solve his guest issue by
>> changing StandardPC HAL into ACPI HAL, using a "hackish" way (by
>> replacing C:\Windows\System32\HAL.DLL into HALACPI.DLL as found
>> on win2k3 installation CDROM).  I wasn't able to replace stdhal
>> into anything else on my test winXP machine - after changing HAL.DLL,
>> on next reboot my guest complains about being unable to find boot
>> device (BSOD STOP 0x7b) - despite using stdIDE and mergeide.  I'll
>> investigate the guest side further later.
>>
>> When in this funky mode with non-working IRQ11 (when a NIC (rtl8139)
>> is assigned to it), winXP guest shows huge delays when trying to
>> open "My Computer" properties - it freezes for 30..40 seconds after
>> hitting "Properties" in the context menu.  I can only guess it is
>> trying to do something with the IRQs at that time, which does not
>> work.  I wasn't able to (quickly) find a tool for winXP to show
>> IRQ statistics.
>>
>> That's about all the info so far which I know about this issue.
> 
> 
> It appears there are two issues here, one is fixed by
> 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and
> another bisect leads to this commit:
> 
> commit 59539c913383fdd3350681301b44f02fa7ee2757
> Author: Jan Kiszka <jan.kiszka@siemens.com>
> Date:   Mon Jun 27 12:22:28 2011 +0200
> 
>     qemu-kvm: Fix in-kernel PIC reset
> 
>     Lacking sync of the user space state to the kernel after system reset
>     left the PIC behind in an undefined state. This broke IRQ delivery in
>     some scenarios, e.g. when resetting while in the BIOS.
> 
>     Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>     Signed-off-by: Avi Kivity <avi@redhat.com>
> 
> 
> Reverting this single commit on top of 0.15.0 fixes the guest issues
> described in this thread.
> 
> This commit is qemu-kvm-specific (and indeed, the issue only affects
> qemu-kvm).
> 
> Note also that as per above, -no-kvm-irqchip fixes the guest issue too.
> 
> Anything wrong with this patch?

I tend to say "no". It may just reveals some issue elsewhere.

To cross-check: Does this series [1] expose the same issue with vanilla
QEMU when enabling that in-kernel irqchip version?

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82871

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux