From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GE22g-0002At-EG for qemu-devel@nongnu.org; Fri, 18 Aug 2006 06:57:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GE22f-00029d-4L for qemu-devel@nongnu.org; Fri, 18 Aug 2006 06:57:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GE22e-00029Z-Ua for qemu-devel@nongnu.org; Fri, 18 Aug 2006 06:57:32 -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 1GE29L-0006kr-MU for qemu-devel@nongnu.org; Fri, 18 Aug 2006 07:04:27 -0400 Received: from lagash (mipsfw.mips-uk.com [194.74.144.146]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 043124579C for ; Fri, 18 Aug 2006 12:57:29 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1GE1AJ-0005UH-5R for qemu-devel@nongnu.org; Fri, 18 Aug 2006 11:01:23 +0100 Date: Fri, 18 Aug 2006 11:01:23 +0100 Subject: Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt? Message-ID: <20060818100122.GC15909@networkno.de> References: <44E3500A.4050608@gmail.com> <20060816182908.GC6387@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Marius Groeger wrote: > On Wed, 16 Aug 2006, Thiemo Seufer wrote: > > >Dirk Behme wrote: > >>Hi, > >> > >>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. > > Dirk and I have been following up on this privately and could verify that it > was indeed an issue with the testcase. QEMU is not causing any problem > here. > > >This explains some weirdness I saw on my hacked up qemu > >when running a mips32r2-compiled Linux kernel. > > What exactly included that hack? Some new mips32r2 insns like rdhw? All new r2 instructions. rdhwr wasn't used by the userland. A recent r2 compiled Kernel will use the di/ei instructions, a recursive exception will IIRC see a EXL flag set when there shouldn't be one. The r1 kernel code happens to mask the EXL flag. Thiemo