[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] debugging apic
From: |
TeLeMan |
Subject: |
Re: [Qemu-devel] debugging apic |
Date: |
Wed, 29 Sep 2010 08:53:14 +0800 |
I reported this bug two year ago, but nobody cared.
http://www.mail-archive.com/address@hidden/msg15330.html
--
SUN OF A BEACH
On Tue, Sep 28, 2010 at 23:15, Sam King <address@hidden> wrote:
> 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
>