[Top][All Lists]

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

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

From: Johannes Schindelin
Subject: [Qemu-devel] Re: Breakage with local APIC routing
Date: Tue, 25 Aug 2009 13:48:57 +0200 (CEST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)


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 \

> Where does the installation fail?

"Setup is starting Windows". (Just after "Setup is loading files (...)" 

> 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 

        (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.


reply via email to

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