[Qemu-devel] Re: Breakage with local APIC routing

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]