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

[Johannes Schindelin]

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.

Ciao,
Dscho