qemu-devel
[Top][All Lists]
Advanced

[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: Sun, 17 Aug 2008 17:00:28 +0200 (CEST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

Hi,

On Wed, 13 Aug 2008, Jan Kiszka wrote:

> 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.
> >>
> >> A bit of research showed that the patch was actually originally from 
> >> Qing He, but he told me privately that the part that actually broke 
> >> win64 (the removal of the call to cpu_reset_interrupt(), as opposed 
> >> to moving that call into the "else" condition) was not part of his 
> >> patch.
> >>
> >> Unfortunately, a lot has been done to the APIC handling in the 
> >> meantime, so it is not a simple matter of a revert.
> >>
> >> Being a complete idiot when it comes to APICs, I have no clue how to 
> >> fix the issue.
> >>
> >> However, I am quite willing to test whatever patch is thrown at me.
> >>
> >> Can somebody help?
> > 
> > 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
> > 
> > However, no one replied on this, and I'm right now not sure if the fix 
> > is OK for all cases. But it is a starting point for new discussion 
> > about what is actually borken here.
> 
> This might not be the last word, but my feeling that it's closer to the
> actual issue than the older fix. Please give it a try. Comments welcome.

I could only quickly test your change, not work on it, but the issue is 
the same.  It seems to run into an endless loop, waiting to be woken up by 
an interrupt (although the latter is just my guess).

Thanks for your help,
Dscho




reply via email to

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