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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60489 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0gco-0004Vz-K2 for qemu-devel@nongnu.org; Tue, 28 Sep 2010 16:18:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0gcn-0003lE-CJ for qemu-devel@nongnu.org; Tue, 28 Sep 2010 16:18:06 -0400 Received: from dscas2.ad.uiuc.edu ([128.174.68.159]:56005) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0gcn-0003kz-82 for qemu-devel@nongnu.org; Tue, 28 Sep 2010 16:18:05 -0400 Message-ID: <4CA248C5.2020409@gmail.com> Date: Tue, 28 Sep 2010 14:57:57 -0500 From: Sam King MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: debugging apic References: <4CA2069D.9040104@uiuc.edu> In-Reply-To: <4CA2069D.9040104@uiuc.edu> Content-Type: multipart/mixed; boundary="------------070607070003070909080909" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --------------070607070003070909080909 Content-Type: multipart/alternative; boundary="------------040902080606050100090004" --------------040902080606050100090004 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Thanks to Bernhard Kauer for pointing out the problem. Apparently if software disables LVT_LINT0 when there is a pending CPU_HARD_INTERRUPT you can get into trouble. I attached a patch that fixes the problem by resetting the interrupt_request. I am not sure if we need to do the same for LINT1, but this fixed the incorrect GPF I was getting. --Sam On 9/28/10 10:15 AM, Sam King 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 --------------040902080606050100090004 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Thanks to Bernhard Kauer for pointing out the problem. Apparently if software disables LVT_LINT0 when there is a pending CPU_HARD_INTERRUPT you can get into trouble. I attached a patch that fixes the problem by resetting the interrupt_request. I am not sure if we need to do the same for LINT1, but this fixed the incorrect GPF I was getting.

--Sam

On 9/28/10 10:15 AM, Sam King 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

--------------040902080606050100090004-- --------------070607070003070909080909 Content-Type: text/plain; x-mac-type=0; x-mac-creator=0; name="apic-race.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="apic-race.patch" *** hw/apic.c 2010-07-22 07:39:04.000000000 -0500 --- ../qemu-0.12.5-fixed/hw/apic.c 2010-09-28 14:45:55.476945540 -0500 *************** *** 841,846 **** --- 841,851 ---- s->lvt[n] = val; if (n == APIC_LVT_TIMER) apic_timer_update(s, qemu_get_clock(vm_clock)); + + if(n == APIC_LVT_LINT0) { + if((val & APIC_LVT_MASKED) && (env->interrupt_request & CPU_INTERRUPT_HARD)) + cpu_reset_interrupt(env, CPU_INTERRUPT_HARD); + } } break; case 0x38: --------------070607070003070909080909-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48457 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0kv7-0002yA-Ua for qemu-devel@nongnu.org; Tue, 28 Sep 2010 20:53:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0kv6-0007PF-Nu for qemu-devel@nongnu.org; Tue, 28 Sep 2010 20:53:17 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:35947) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0kv6-0007P6-Kq for qemu-devel@nongnu.org; Tue, 28 Sep 2010 20:53:16 -0400 Received: by gxk22 with SMTP id 22so141748gxk.4 for ; Tue, 28 Sep 2010 17:53:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4CA2069D.9040104@uiuc.edu> References: <4CA2069D.9040104@uiuc.edu> Date: Wed, 29 Sep 2010 08:53:14 +0800 Message-ID: Subject: Re: [Qemu-devel] debugging apic From: TeLeMan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sam King Cc: qemu-devel@nongnu.org SSByZXBvcnRlZCB0aGlzIGJ1ZyB0d28geWVhciBhZ28sIGJ1dCBub2JvZHkgY2FyZWQuCmh0dHA6 Ly93d3cubWFpbC1hcmNoaXZlLmNvbS9xZW11LWRldmVsQG5vbmdudS5vcmcvbXNnMTUzMzAuaHRt bAotLQpTVU4gT0YgQSBCRUFDSAoKCgpPbiBUdWUsIFNlcCAyOCwgMjAxMCBhdCAyMzoxNSwgU2Ft IEtpbmcgPGtpbmdzdEB1aXVjLmVkdT4gd3JvdGU6Cj4gSGVsbG8sCj4KPiBJIGFtIHNlZWluZyBh IHdlaXJkIGNyYXNoIGluIG15IHN5c3RlbSBhbmQgSSBhbSB0cnlpbmcgdG8gZmlndXJlIG91dCBp ZiBpdAo+IGlzIGEgc29mdHdhcmUgYnVnIG9yIGEgcWVtdSBlbXVsYXRpb24gYnVnLsKgIEZyb20g dGhlIHNvZnR3YXJlIHBlcnNwZWN0aXZlIEkKPiBhbSBnZXR0aW5nIGEgR1AgZmF1bHQgYXQgYSB0 aW1lIHdoZXJlIGl0IGxvb2tzIGxpa2UgZXZlcnl0aGluZyBzaG91bGQgYmUKPiBydW5uaW5nIG5v cm1hbGx5LsKgIEFmdGVyIGRpZ2dpbmcgaW50byB0aGUgUWVtdSBzb3VyY2UgY29kZSBJIGZvdW5k IG91dCB3aGVyZQo+IHRoZSBHUEYgd2FzIGNvbWluZyBmcm9tLsKgIEl0IGxvb2tzIGxpa2UgaW50 bm8gPSAtMSB3aGVuIGl0IHdhcyBiZWluZyBwYXNzZWQKPiBpbnRvIGRvX2ludGVycnVwdDY0LCB3 aGljaCB3YXMgdHJpZ2dlcmluZyBvbmUgb2YgdGhlIEdQRiBjaGVja3MuwqAgRnJvbSB3aGF0Cj4g SSBjYW4gdGVsbCwgaW50bm8gd2FzIGJlaW5nIHNldCB0byAtMSBieSBhbiBpbnRlcnJ1cHRfcmVx dWVzdCBpbiBjcHUtZXhlYy5jLAo+IHdoaWNoIHdhcyBnb2luZyBkb3duIHRoZSBmb2xsb3dpbmcg aWYgc3RhdGVtZW50IGFyb3VuZCBsaW5lIDQwOSBvZiB0aGF0Cj4gZmlsZToKPgo+IGVsc2UgaWYg KChpbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKPiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAoKChlbnYtPmhmbGFnczIgJiBIRjJfVklOVFJfTUFTSykgJiYKPiDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg KGVudi0+aGZsYWdzMiAmIEhGMl9ISUZfTUFTSykpIHx8Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAoIShlbnYt PmhmbGFnczIgJiBIRjJfVklOVFJfTUFTSykgJiYKPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKGVudi0+ZWZs YWdzICYgSUZfTUFTSyAmJgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICEoZW52LT5oZmxhZ3MgJgo+IEhG X0lOSElCSVRfSVJRX01BU0spKSkpKQo+Cj4gYW5kIGZyb20gd2l0aGluIHRoYXQgZWxzZSBpZiBz dGF0ZW1lbnQsIGVudiBoYXMgdGhlIGZvbGxvd2luZyBzdGF0ZToKPgo+IGhmbGFnczIgPSAweDAw MDAwMDAxCj4gZWZsYWdzID0gMHgwMDAwMzIwMgo+IGhmbGFncyA9IDB4MDA0MGMwYjcKPiBpbnRl cnJ1cHQgcmVxdWVzdCA9IDB4MDAwMDAwMDIKPgo+IEJ1dCBpbnRubyBpcyBiZWluZyBzZXQgZXF1 YWwgdG8gLTEgYnkgdGhlIGNhbGwgdG8gY3B1X2dldF9waWNfaW50ZXJydXB0LAo+IGZyb20gdGhl IGNhbGwgdG8gYXBpY19hY2NlcHRfcGljX2ludHIgcmV0dXJuaW5nIDAuwqAgSWYgSSBjaGFuZ2Ug dGhlCj4gY3B1X2dldF9waWNfaW50ZXJydXB0IGNvZGUgdG8gdGhpczoKPgo+IGludCBjcHVfZ2V0 X3BpY19pbnRlcnJ1cHQoQ1BVU3RhdGUgKmVudikKPiB7Cj4gwqDCoMKgIGludCBpbnRubzsKPgo+ IMKgwqDCoCBpbnRubyA9IGFwaWNfZ2V0X2ludGVycnVwdChlbnYpOwo+IMKgwqDCoCBpZiAoaW50 bm8gPj0gMCkgewo+IMKgwqDCoMKgwqDCoMKgIC8qIHNldCBpcnEgcmVxdWVzdCBpZiBhIFBJQyBp cnEgaXMgc3RpbGwgcGVuZGluZyAqLwo+IMKgwqDCoMKgwqDCoMKgIC8qIFhYWDogaW1wcm92ZSB0 aGF0ICovCj4gwqDCoMKgwqDCoMKgwqAgcGljX3VwZGF0ZV9pcnEoaXNhX3BpYyk7Cj4gwqDCoMKg wqDCoMKgwqAgcmV0dXJuIGludG5vOwo+IMKgwqDCoCB9Cj4gwqDCoMKgIC8qIHJlYWQgdGhlIGly cSBmcm9tIHRoZSBQSUMgKi8KPiDCoMKgwqAgaWYgKCFhcGljX2FjY2VwdF9waWNfaW50cihlbnYp KSB7Cj4gwqDCoMKgwqDCoMKgwqAgLy9yZXR1cm4gLTE7Cj4gwqDCoMKgIH0KPgo+IMKgwqDCoCBp bnRubyA9IHBpY19yZWFkX2lycShpc2FfcGljKTsKPgo+IMKgwqDCoCByZXR1cm4gaW50bm87Cj4g fQo+Cj4gVGhlbiB0aGUgaXNzdWUgbWFuaWZlc3RzIGFzIGEgc3B1cmlvdXMgaW50ZXJydXB0IGFu ZCB0aGUgc29mdHdhcmUgaWdub3Jlcwo+IGl0LCBhdm9pZGluZyB0aGUgR1BGLsKgIERvZXMgYW55 b25lIGhhdmUgYW55IGlkZWFzIGFzIHRvIHdoYXQgaXMgZ29pbmcgd3JvbmcKPiBoZXJlP8KgIFNo b3VsZCBJIGxvb2sgbW9yZSBjbG9zZWx5IGF0IHRoZSBRZW11IGVtdWxhdGlvbiBjb2RlIG9yIG15 IHNvZnR3YXJlPwo+IEFueSBoZWxwIGlzIGFwcHJlY2lhdGVkLgo+Cj4gVGhhbmtzIQo+Cj4gLS1T YW0KPgo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52069 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0qPI-00063P-KG for qemu-devel@nongnu.org; Wed, 29 Sep 2010 02:44:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0qPH-000337-BI for qemu-devel@nongnu.org; Wed, 29 Sep 2010 02:44:48 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:56380) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0qPG-00032z-VL for qemu-devel@nongnu.org; Wed, 29 Sep 2010 02:44:47 -0400 Message-ID: <4CA2E057.80204@web.de> Date: Wed, 29 Sep 2010 08:44:39 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4CA2069D.9040104@uiuc.edu> <4CA248C5.2020409@gmail.com> In-Reply-To: <4CA248C5.2020409@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig751432A30AA09EABF06ACBC6" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: PATCH: debugging apic List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sam King Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig751432A30AA09EABF06ACBC6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 28.09.2010 21:57, Sam King wrote: > Thanks to Bernhard Kauer for pointing out the problem. Apparently if > software disables LVT_LINT0 when there is a pending CPU_HARD_INTERRUPT > you can get into trouble. I attached a patch that fixes the problem by= > resetting the interrupt_request. I am not sure if we need to do the > same for LINT1, but this fixed the incorrect GPF I was getting. >=20 =2E.. [ please inline patches ] > *** hw/apic.c 2010-07-22 07:39:04.000000000 -0500 > --- ../qemu-0.12.5-fixed/hw/apic.c 2010-09-28 14:45:55.476945540 -0500 > *************** > *** 841,846 **** > --- 841,851 ---- > s->lvt[n] =3D val; > if (n =3D=3D APIC_LVT_TIMER) > apic_timer_update(s, qemu_get_clock(vm_clock)); > +=20 > + if(n =3D=3D APIC_LVT_LINT0) { > + if((val & APIC_LVT_MASKED) && (env->interrupt_request= & CPU_INTERRUPT_HARD)) > + cpu_reset_interrupt(env, CPU_INTERRUPT_HARD); > + } > } > break; > case 0x38: This actually points out open issues, but more work is required: You need to consider other potentially pending interrupts as well, thus you must not blindly reset here. And the same is true for invocations of apic_deliver_pic_intr(..., 0). The APIC has to save the PIC line state and forward it according to its current LVT mask state, which includes raising the interrupt if the mask is removed while the PIC line is high. Jan --------------enig751432A30AA09EABF06ACBC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyi4FsACgkQitSsb3rl5xR+mwCg66Vh4/g+0VR/yGSZUCqxZX5X tZMAoKn6LLVnl8FywCRd3OmNMx8IAsbQ =FrST -----END PGP SIGNATURE----- --------------enig751432A30AA09EABF06ACBC6-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48749 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0zpe-0008FF-98 for qemu-devel@nongnu.org; Wed, 29 Sep 2010 12:48:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0zox-0001yH-Vm for qemu-devel@nongnu.org; Wed, 29 Sep 2010 12:47:57 -0400 Received: from dscas2.ad.uiuc.edu ([128.174.68.159]:17895) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0zox-0001y0-RU for qemu-devel@nongnu.org; Wed, 29 Sep 2010 12:47:55 -0400 Message-ID: <4CA36DB9.6040801@gmail.com> Date: Wed, 29 Sep 2010 11:47:53 -0500 From: Sam King MIME-Version: 1.0 References: <4CA2069D.9040104@uiuc.edu> <4CA248C5.2020409@gmail.com> <4CA2E057.80204@web.de> In-Reply-To: <4CA2E057.80204@web.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: PATCH: debugging apic List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org Thanks for the info. I started looking at the APIC logic and fixing the behavior is going to take me a little bit of time to make sure that I keep all of the APIC states consistent. In the meantime, TeLeMan suggested a patch a few years ago that would fix this (and potentially other) problems. I have updated this patch and included it in this email: *** cpu-exec.c 2010-07-22 07:39:04.000000000 -0500 --- ../qemu-0.12.5-fixed/cpu-exec.c 2010-09-29 11:41:25.991566727 -0500 *************** *** 388,396 **** (env->eflags & IF_MASK && !(env->hflags & HF_INHIBIT_IRQ_MASK))))) { int intno; - svm_check_intercept(SVM_EXIT_INTR); env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ); intno = cpu_get_pic_interrupt(env); qemu_log_mask(CPU_LOG_TB_IN_ASM, "Servicing hardware INT=0x%02x\n", intno); #if defined(__sparc__) && !defined(CONFIG_SOLARIS) #undef env --- 388,397 ---- (env->eflags & IF_MASK && !(env->hflags & HF_INHIBIT_IRQ_MASK))))) { int intno; env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ); intno = cpu_get_pic_interrupt(env); + if(intno >= 0) { + svm_check_intercept(SVM_EXIT_INTR); qemu_log_mask(CPU_LOG_TB_IN_ASM, "Servicing hardware INT=0x%02x\n", intno); #if defined(__sparc__) && !defined(CONFIG_SOLARIS) #undef env *************** *** 401,406 **** --- 402,409 ---- /* ensure that no TB jump will be modified as the program flow was changed */ next_tb = 0; + } + #if !defined(CONFIG_USER_ONLY) } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) && (env->eflags & IF_MASK) && On 9/29/10 1:44 AM, Jan Kiszka wrote: > Am 28.09.2010 21:57, Sam King wrote: >> Thanks to Bernhard Kauer for pointing out the problem. Apparently if >> software disables LVT_LINT0 when there is a pending CPU_HARD_INTERRUPT >> you can get into trouble. I attached a patch that fixes the problem by >> resetting the interrupt_request. I am not sure if we need to do the >> same for LINT1, but this fixed the incorrect GPF I was getting. >> > ... > [ please inline patches ] > >> *** hw/apic.c 2010-07-22 07:39:04.000000000 -0500 >> --- ../qemu-0.12.5-fixed/hw/apic.c 2010-09-28 14:45:55.476945540 -0500 >> *************** >> *** 841,846 **** >> --- 841,851 ---- >> s->lvt[n] = val; >> if (n == APIC_LVT_TIMER) >> apic_timer_update(s, qemu_get_clock(vm_clock)); >> + >> + if(n == APIC_LVT_LINT0) { >> + if((val& APIC_LVT_MASKED)&& (env->interrupt_request& CPU_INTERRUPT_HARD)) >> + cpu_reset_interrupt(env, CPU_INTERRUPT_HARD); >> + } >> } >> break; >> case 0x38: > This actually points out open issues, but more work is required: > > You need to consider other potentially pending interrupts as well, thus > you must not blindly reset here. And the same is true for invocations of > apic_deliver_pic_intr(..., 0). The APIC has to save the PIC line state > and forward it according to its current LVT mask state, which includes > raising the interrupt if the mask is removed while the PIC line is high. > > Jan >