From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59711 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0cEa-0006zp-7F for qemu-devel@nongnu.org; Tue, 28 Sep 2010 11:36:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0cEX-0002zf-BE for qemu-devel@nongnu.org; Tue, 28 Sep 2010 11:36:46 -0400 Received: from dscas2.ad.uiuc.edu ([128.174.68.159]:3879) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0cEX-0002xd-1q for qemu-devel@nongnu.org; Tue, 28 Sep 2010 11:36:45 -0400 Message-ID: <4CA2069D.9040104@uiuc.edu> Date: Tue, 28 Sep 2010 10:15:41 -0500 From: Sam King MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080802050800030901000606" Subject: [Qemu-devel] debugging apic List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --------------080802050800030901000606 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hello, I am seeing a weird crash in my system and I am trying to figure out if it is a software bug or a qemu emulation bug. From the software perspective I am getting a GP fault at a time where it looks like everything should be running normally. After digging into the Qemu source code I found out where the GPF was coming from. It looks like intno = -1 when it was being passed into do_interrupt64, which was triggering one of the GPF checks. From what I can tell, intno was being set to -1 by an interrupt_request in cpu-exec.c, which was going down the following if statement around line 409 of that file: else if ((interrupt_request & CPU_INTERRUPT_HARD) && (((env->hflags2 & HF2_VINTR_MASK) && (env->hflags2 & HF2_HIF_MASK)) || (!(env->hflags2 & HF2_VINTR_MASK) && (env->eflags & IF_MASK && !(env->hflags & HF_INHIBIT_IRQ_MASK))))) and from within that else if statement, env has the following state: hflags2 = 0x00000001 eflags = 0x00003202 hflags = 0x0040c0b7 interrupt request = 0x00000002 But intno is being set equal to -1 by the call to cpu_get_pic_interrupt, from the call to apic_accept_pic_intr returning 0. If I change the cpu_get_pic_interrupt code to this: int cpu_get_pic_interrupt(CPUState *env) { int intno; intno = apic_get_interrupt(env); if (intno >= 0) { /* set irq request if a PIC irq is still pending */ /* XXX: improve that */ pic_update_irq(isa_pic); return intno; } /* read the irq from the PIC */ if (!apic_accept_pic_intr(env)) { //return -1; } intno = pic_read_irq(isa_pic); return intno; } Then the issue manifests as a spurious interrupt and the software ignores it, avoiding the GPF. Does anyone have any ideas as to what is going wrong here? Should I look more closely at the Qemu emulation code or my software? Any help is appreciated. Thanks! --Sam --------------080802050800030901000606 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hello,

I am seeing a weird crash in my system and I am trying to figure out if it is a software bug or a qemu emulation bug.  From the software perspective I am getting a GP fault at a time where it looks like everything should be running normally.  After digging into the Qemu source code I found out where the GPF was coming from.  It looks like intno = -1 when it was being passed into do_interrupt64, which was triggering one of the GPF checks.  From what I can tell, intno was being set to -1 by an interrupt_request in cpu-exec.c, which was going down the following if statement around line 409 of that file:

else if ((interrupt_request & CPU_INTERRUPT_HARD) &&
                                   (((env->hflags2 & HF2_VINTR_MASK) &&
                                     (env->hflags2 & HF2_HIF_MASK)) ||
                                    (!(env->hflags2 & HF2_VINTR_MASK) &&
                                     (env->eflags & IF_MASK &&
                                      !(env->hflags & HF_INHIBIT_IRQ_MASK)))))

and from within that else if statement, env has the following state:

hflags2 = 0x00000001
eflags = 0x00003202
hflags = 0x0040c0b7
interrupt request = 0x00000002

But intno is being set equal to -1 by the call to cpu_get_pic_interrupt, from the call to apic_accept_pic_intr returning 0.  If I change the cpu_get_pic_interrupt code to this:

int cpu_get_pic_interrupt(CPUState *env)
{
    int intno;

    intno = apic_get_interrupt(env);
    if (intno >= 0) {
        /* set irq request if a PIC irq is still pending */
        /* XXX: improve that */
        pic_update_irq(isa_pic);
        return intno;
    }
    /* read the irq from the PIC */
    if (!apic_accept_pic_intr(env)) {
        //return -1;
    }

    intno = pic_read_irq(isa_pic);

    return intno;
}

Then the issue manifests as a spurious interrupt and the software ignores it, avoiding the GPF.  Does anyone have any ideas as to what is going wrong here?  Should I look more closely at the Qemu emulation code or my software? Any help is appreciated.

Thanks!

--Sam
 --------------080802050800030901000606--