From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FbNPx-0004PZ-N4 for qemu-devel@nongnu.org; Wed, 03 May 2006 15:53:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FbNPv-0004PK-Qi for qemu-devel@nongnu.org; Wed, 03 May 2006 15:53:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FbNPv-0004PH-JQ for qemu-devel@nongnu.org; Wed, 03 May 2006 15:53:47 -0400 Received: from [193.7.176.20] (helo=bender.bawue.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FbNQM-0008U5-Sr for qemu-devel@nongnu.org; Wed, 03 May 2006 15:54:15 -0400 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id EAFD14575E for ; Wed, 3 May 2006 21:53:44 +0200 (MEST) Received: from ths by lagash with local (Exim 4.61) (envelope-from ) id 1FbNP8-0007bO-9p for qemu-devel@nongnu.org; Wed, 03 May 2006 20:52:58 +0100 Date: Wed, 3 May 2006 20:52:58 +0100 Subject: Re: [Qemu-devel] MIPS interrupt handling Message-ID: <20060503195258.GB18218@networkno.de> References: <4457DD1F.7040307@bellard.org> <20060502234421.GK5004@networkno.de> <4459013C.4040002@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4459013C.4040002@bellard.org> From: Thiemo Seufer Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Fabrice Bellard wrote: > Thiemo Seufer wrote: > >Fabrice Bellard wrote: > > > >>I just looked at the MIPS file target-mips/op_helper.c and I don't > >>understand why IRQs need to be handled in op_helper.c:do_mtc0() with reg > >>= 12. > > > > > >Register 12 is the cp0_status register, it defines which interrupts are > >masked/enabled/disabled. Btw, I have a patch which moves this to op.c, > >this should improve performance a bit (and avoids the TB stop for > >most mtc0 writes). > > op.c should only contain small functions so it is not a good idea. TB > stop after mtc0 is needed at least when the TLB are modified or to > handle the interrupts. Agreed for the cp0_status part, the other functions are small (probably except cp_cause) and most of them don't need TB stop. > The current handling of interrupts in mtc0 must > be suppressed ASAP as it is not useful and complicates the code. > > >>IMHO, the corresponding code should be deleted because the TB is > >>forced to terminate after mtc0 so that the IRQs can be handled in the > >>main loop in cpu-exec.c. > >> > >>Moreover, clearing CPU_INTERRUPT_HARD in do_mtc0() is almost surely a bug > >>! > > > > > >Somehow the interrupt assert has to be prevented when St0_IE is cleared. > >That's probably also a job for the main loop, but there may be a race > >condition (haven't looked yet). Empirically, it works well. :-) > > If ST0_IE means interrupt enable, the interrupt assert must not be > suppressed, but I did not read yet this part of the MIPS spec... As I tried to explain, I suspect there's a race between disabling interrupts via ST0_IE and turning them off in the exception handling code. For the enable part, it shouldn't matter that much. Thiemo