Message: 5
Date: Wed, 26 Aug 2009 09:31:26 +0200
From: Jan Kiszka <jan.kiszka@web.de>
Subject: [Qemu-devel] Re: Breakage with local APIC routing
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: qemu-devel@nongnu.org, Avi Kivity <avi@qumranet.com>
Message-ID: <4A94E4CE.4020903@web.de>
Content-Type: text/plain; charset="iso-8859-1"

Johannes Schindelin wrote:
> Hi,
>
> On Tue, 25 Aug 2009, Jan Kiszka wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Tue, 25 Aug 2009, Jan Kiszka wrote:
>>>
>>>> Johannes Schindelin wrote:
>>>>
>>>>> On Sun, 17 Aug 2008, Jan Kiszka wrote:
>>>>>
>>>>>> Johannes Schindelin wrote:
>>>>>>
>>>>>>> On Wed, 13 Aug 2008, Jan Kiszka wrote:
>>>>>>>
>>>>>>>> Johannes Schindelin wrote:
>>>>>>>>> due to the change in revision 3371 (well, at that time, CVS was
>>>>>>>>> used, which was no better than Subversion) installation of win64
>>>>>>>>> is broken in QEmu.  The commit message reads like this:
>>>>>>>>>
>>>>>>>>>       Don't route PIC interrupts through the local APIC if the local
>>>>>>>>>       APIC config says so. By Ari Kivity.
>>>>>>>> I recalled some earlier post on this which claimed to fix the issue
>>>>>>>> and found it in the archive:
>>>>>>>>
>>>>>>>> http://permalink.gmane.org/gmane.comp.emulators.qemu/25415
 

>>>>>>> I tried this, and it changes the symptoms, indeed.  Instead of an
>>>>>>> endless loop, it results in a bluescreen.
>>>>>>>
>>>>>>> As the OP said that it worked for him, I guess it is either in
>>>>>>> commits that came after his post, or in my add-on patches.
>>>>>> So we are likely on the wrong path. Maybe we have to understand what
>>>>>> happens here first...
>>>>>>
>>>>>>> Hopefully I will find some time to work more on this bug.
>>>>>> Would be interesting to know
>>>>>>  - if pic_irq_request is continuously called or if it stops when windows
>>>>>>    hangs
>>>>>>  - what IRQ vectors are delivered
>>>>>>  - in what state the apic is, namely the s->lvt[APIC_LVT_LINT0]
>>>>> Sorry for the long delay.  I just don't have time to take care of the
>>>>> issue, but I quickly verified that it still does not work, with aa0cba4
>>>>> (Aug 13 2009).
>>>>>
>>>>> If you are still interested in this issue, could you give me a hint
>>>>> _where_ I should output _which_ values?  I'll gladly take time for that
>>>>> now.
>>>> If some OS does not properly install due to a possible emulation bug, I
>>>> am interested, for sure. Let's restart this by specifying the test case
>>>> more precisely: What version of Windows are you trying to install?
>>> As far as I remember, it is a plain version of 64-bit XP Pro.  (Maybe it
>>> is a custom .iso for my day-job, but I think this is not the case).
>>>
>>>> What is your qemu command line?
>>> test -h pc-bios/keymaps || ln -s ../keymaps pc-bios/
>>>
>>> ./x86_64-softmmu/qemu-system-
x86_64 \
>>>         -L pc-bios/ \
>>>         -m 1024 \
>>>         -monitor stdio \
>>>         -k en-us \
>>>         -hda w64.img \
>>>         -cdrom en_win_xp_pro_x64bit.iso \
>>>         -fda fat:fat \
>>>         -boot d \
>>>         -net none \
>>>         -localtime
>>>
>>>> Where does the installation fail?
>>> "Setup is starting Windows". (Just after "Setup is loading files (...)"
>>> phase.)
>>>
>>>> Are there specific steps required during the installation to reproduce
>>>> the problem?
>>> You need a 64-bit XP Pro, then call the command line as I did.  It hangs
>>> at
>>>
>>>     (qemu) info cpus
>>>     * CPU #0: pc=0xfffff800010cabeb
>>>
>>> This is 100% reproducible.
>>>
>>>> And one more question: Did you check that you were using the
>>>> corresponding BIOS to aa0cba4?
>>> Yes, I always use -L pc-bios/ in the same Git working directory, and I
>>> just verified that indeed, the source is clean.
>>>
>>> A tiny, gentle reminder: the revision which is now available as 0e21e12b
>>> introduced this particular breakage.
>> OK, just found some 64-bit Windows ISO (Server 2003) that also makes no
>> progress at the point you described. Will play with it later today,
>> specifically with the LAPIC changes you referred to.
>
> Thank you very much!
>
> If you need me to test something, just let me know; I'll try to squeeze
> that into my time schedule.

>Very strange problem: I managed to get past this "Setup is starting
>Windows", but only when using KVM mode (both -enable-kvm from upstream
>as well as w/ or w/o -no-kvm-irqchip from qemu-kvm). It still takes ages
>(several minutes), but it works. The version before the commit you
> pointed out does not take so much time for this step.
>
> So we may see two issues here: some x86 emulation problem in TCG mode
> plus some IRQ delivery incorrectness.
>
> Did anyone here recently try to install XP-64 (desktop or server) into
> qemu or qemu-kvm recently? Can you confirm long delays or hangs during
> "Setup is starting Windows" (early text-mode installer)?
>
> Jan
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 257 bytes
> Desc: OpenPGP digital signature
> Url : http://lists.gnu.org/pipermail/qemu-devel/attachments/20090826/77c8e2b3/signature.bin
 

Hello,

 I have just downloaded the latest qemu sources -qemu-0.11.0-rc2, builded them for Windows (using mingw, the tutorial described here: http://www.h7.dion.ne.jp/~qemu-win/PortingTips-en.html). I was going to use qemu-system-x86_64.exe to emulate a Windows XP 64 on 32bit machine. The setup hangs at the same step (Setup is starting Windows). It is 100% reproductible for me.