From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FpTLh-0005yh-8i
	for qemu-devel@nongnu.org; Sun, 11 Jun 2006 13:03:41 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FpTLg-0005yV-KB
	for qemu-devel@nongnu.org; Sun, 11 Jun 2006 13:03:40 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FpTLg-0005yQ-HV
	for qemu-devel@nongnu.org; Sun, 11 Jun 2006 13:03:40 -0400
Received: from [64.233.182.184] (helo=nf-out-0910.google.com)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1FpTUD-0005hT-MI
	for qemu-devel@nongnu.org; Sun, 11 Jun 2006 13:12:29 -0400
Received: by nf-out-0910.google.com with SMTP id k27so561861nfc
	for <qemu-devel@nongnu.org>; Sun, 11 Jun 2006 10:03:39 -0700 (PDT)
Message-ID: <448C4CF2.6000308@gmail.com>
Date: Sun, 11 Jun 2006 19:03:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Dirk Behme <dirk.behme@googlemail.com>
Subject: [Qemu-devel] Simulation of MIPS interrupts?
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

Hi,

looking in cpu_exec.c at cpu_exec() there are two code 
blocks which call MIPS interrupt handling code (please see 
below, (a) & (b) )

When is which block called?

I ask because a simple MIPS IRQ test doesn't work for me 
like I would expect. I enable interrupts in status register. 
Then, using code (b), system jumps to 0xbfc00380 like 
expected. My expectation would be that I now can do 
everything in ISR. As long as EXL is set it locks out 
interrupts globally (like done in code (b) ). Even touching 
HW and raising an additional IRQ in ISR shouldn't come 
through until first called ISR exits with 'eret'. This is 
what is checked in code (b): As long EXL ist set, 
do_interrupt() isn't called again there.

But if additional IRQ is raised while in ISR, block (a) is 
called (which does no checks like code (b)), system jumps to 
0xbfc00380, executes ~7-8 assembly instructions and jumps 
again to 0xbfc00380 via block (a). This results in an 
infinite loop. eret of first ISR is never executed:

IRQ
exec (b)
jump 0xbfc00380
do sth, issue second IRQ
IRQ
exec (a)
jump 0xbfc00380
do ~7-8 assembly instructions
exec (a)
jump 0xbfc00380
do ~7-8 assembly instructions
exec (a)
jump 0xbfc00380
do ~7-8 assembly instructions
...

Best regards

Dirk

(a)
...
#elif defined(TARGET_MIPS)
                     do_interrupt(env);
#elif defined(TARGET_SPARC)
...

(b)
...
#elif defined(TARGET_MIPS)
                     if ((interrupt_request & 
CPU_INTERRUPT_HARD) &&
                         (env->CP0_Status & (1 << CP0St_IE)) &&
                         (env->CP0_Status & env->CP0_Cause & 
0x0000FF00) &&
                         !(env->hflags & MIPS_HFLAG_EXL) &&
                         !(env->hflags & MIPS_HFLAG_ERL) &&
                         !(env->hflags & MIPS_HFLAG_DM)) {
                         /* Raise it */
                         env->exception_index = 
EXCP_EXT_INTERRUPT;
                         env->error_code = 0;
                         do_interrupt(env);
                         env->interrupt_request &= 
~CPU_INTERRUPT_HARD;
...