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

[Jan Kiszka]

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.

I'm starting to get clueless about this issue. It looks like a timing
issue as I was able to crash Windows when using qemu-kvm (in kvm mode)
and attaching a guest debugger to the "right" spot. As you may know,
this also happens today (after dyngen to TCG switch) when resetting the
CPU interrupt in pic_irq_request on !level. To exclude that Windows is
simply fragile here, I need a better test case, ideally some with source
code. Think I will look into Mohammed's Ubuntu case again.

Jan

signature.asc
Description: OpenPGP digital signature