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 >