[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Kiszka
Subject: [Qemu-devel] Re: Breakage with local APIC routing
Date: Tue, 25 Aug 2009 14:31:02 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Johannes Schindelin wrote:
> Hi,
> 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.

Thanks so far,

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]