From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1GDRqO-0004RI-Hg
	for qemu-devel@nongnu.org; Wed, 16 Aug 2006 16:18:28 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1GDRqN-0004Pi-E2
	for qemu-devel@nongnu.org; Wed, 16 Aug 2006 16:18:28 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1GDRqN-0004PU-95
	for qemu-devel@nongnu.org; Wed, 16 Aug 2006 16:18:27 -0400
Received: from [66.249.92.172] (helo=ug-out-1314.google.com)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1GDRwh-0005P7-Qj
	for qemu-devel@nongnu.org; Wed, 16 Aug 2006 16:25:00 -0400
Received: by ug-out-1314.google.com with SMTP id s2so303725uge
	for <qemu-devel@nongnu.org>; Wed, 16 Aug 2006 13:18:26 -0700 (PDT)
Message-ID: <44E37D8E.3050801@gmail.com>
Date: Wed, 16 Aug 2006 22:18:22 +0200
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
References: <44E3500A.4050608@gmail.com> <20060816182908.GC6387@networkno.de>
In-Reply-To: <20060816182908.GC6387@networkno.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Dirk Behme <dirk.behme@googlemail.com>
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

Thiemo Seufer wrote:
> Dirk Behme wrote:
>>I'm not sure, but while playing with MIPS interrupts, it 
>>seems to me that something with reset of interrupt flag 
>>MIPS_HFLAG_EXL (0x04) at exception exit (eret) is wrong. It 
>>seems to me that only one interrupt is executed because 
>>after eret, MIPS_HFLAG_EXL stays set in env->hflags. Then, 
>>at next interrupt, system correctly checks for 
>>MIPS_HFLAG_EXL, but this is still set and no further 
>>interrupt happens.
> 
> This explains some weirdness I saw on my hacked up qemu
> when running a mips32r2-compiled Linux kernel.

This was the reason why I first tried it with a small test 
program before using Linux ;)

>>Debugging shows that op_eret() in MIPS op.c correctly reset 
>>this bit: env->hflags &= ~MIPS_HFLAG_EXL; But debug output 
>>at end of e.g. save_cpu_state() (debug output of ctx->hflags 
>>and ctx->saved_hflags ) or in function which tries to issue 
>>(next) timer interrupt (debug output of env->hflags) 
>>MIPS_HFLAG_EXL is still (again?) set everywhere. Looks like 
>>the correct env->hflags from op_eret() is overwritten 
>>somewhere later with wrong value.
>>
>>These three ctx->hflags, ctx->saved_hflags and env->hflags 
>>are confusing me ;) Where are they synchronized after eret? 
>>Or who overwrites the env->hflags correctly set by eret 
>>again? Any ideas, why eret sets env->hflags correctly and 
>>later global env->hflags has still/again wrong value? Any 
>>other hints?
> 
> AFAIU qemu maintains an environment stack, I guess popping the
> environment restores the old flag contents.

Anybody with a short explanation of the basics of this? I 
think this would really help debugging this issue.

Many thanks

Dirk