From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Fb3N6-0001WL-UL
	for qemu-devel@nongnu.org; Tue, 02 May 2006 18:29:32 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Fb3N5-0001W6-D3
	for qemu-devel@nongnu.org; Tue, 02 May 2006 18:29:31 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Fb3N5-0001W3-9Q
	for qemu-devel@nongnu.org; Tue, 02 May 2006 18:29:31 -0400
Received: from [84.96.92.61] (helo=sMtp.neuf.fr)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fb3NK-00076B-IT
	for qemu-devel@nongnu.org; Tue, 02 May 2006 18:29:46 -0400
Received: from [84.102.211.71] by sp604002mt.gpm.neuf.ld
	(Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006))
	with ESMTP id <0IYN00DCET564IK0@sp604002mt.gpm.neuf.ld> for
	qemu-devel@nongnu.org; Wed, 03 May 2006 00:29:30 +0200 (CEST)
Date: Wed, 03 May 2006 00:28:47 +0200
From: Fabrice Bellard <fabrice@bellard.org>
Message-id: <4457DD1F.7040307@bellard.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Subject: [Qemu-devel] MIPS interrupt handling
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

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. 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 !

Fabrice.