From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3sjR-0003Rs-KY for qemu-devel@nongnu.org; Sat, 03 Mar 2012 12:26:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3sjP-0007BX-3Z for qemu-devel@nongnu.org; Sat, 03 Mar 2012 12:26:57 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:41052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3sjO-0007BK-Tg for qemu-devel@nongnu.org; Sat, 03 Mar 2012 12:26:55 -0500 Message-ID: <4F525458.3000809@codesourcery.com> Date: Sat, 3 Mar 2012 11:26:48 -0600 From: Meador Inge MIME-Version: 1.0 References: <1330722210-13488-1-git-send-email-meadori@codesourcery.com> <4F524A96.3030206@suse.de> In-Reply-To: <4F524A96.3030206@suse.de> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v1 1/1] mips: properly compute hflags and fcr0 on cpu reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: Khansa Butt , "Maciej W. Rozycki" , qemu-devel@nongnu.org, aurelien@aurel32.net On 03/03/2012 10:45 AM, Andreas Färber wrote: > Am 02.03.2012 22:03, schrieb Meador Inge: >> Currently 'cpu_reset' doesn't fully compute all of the needed >> HFLAGs and fails to setup fcr0 after clearing the CPU state. >> This can cause instruction exceptions. For example, using >> 'madd.d' on machines that should support it is kindly greeted >> with: >> >> qemu: uncaught target signal 4 (Illegal instruction) - core dumped >> Illegal instruction (core dumped) >> >> because fcr0 is bogus and MIPS_HFLAG_COP1X is not correcly set in hflags. >> >> This is fixed by modifying 'cpu_reset' to use 'compute_hflags' and >> initializing 'fcr0' from the current CPU model. > > fcr0 issue has also been > > Reported-by: Khansa Butt > > e.g., http://patchwork.ozlabs.org/patch/133974/ Ah, thanks. The fcr0 fix had been sitting in our local tree for a while and I just forgot to check upstream patch submissions. I need to get in the habit of looking at patchwork first. > Your use of compute_hflags() looks more future-proof. > >> >> Signed-off-by: Maciej W. Rozycki >> Signed-off-by: Nathan Froyd >> Signed-off-by: Meador Inge >> --- >> target-mips/cpu.h | 49 +++++++++++++++++++++++++++++++++++++++++++++++ >> target-mips/op_helper.c | 49 ----------------------------------------------- >> target-mips/translate.c | 17 +++------------ >> 3 files changed, 53 insertions(+), 62 deletions(-) >> >> diff --git a/target-mips/cpu.h b/target-mips/cpu.h >> index 71cb4e8..fc65348 100644 >> --- a/target-mips/cpu.h >> +++ b/target-mips/cpu.h >> @@ -737,4 +737,53 @@ static inline void cpu_pc_from_tb(CPUState *env, TranslationBlock *tb) >> env->hflags |= tb->flags & MIPS_HFLAG_BMASK; >> } >> >> +static inline void compute_hflags(CPUState *env) >> +{ > > Moving helper functions like these to cpu.h has proven troublesome for > QOM'ification (when they need access to MIPSCPU[Class] in addition to > CPUMIPSState) but it'll do for now. Okay, I will keep that in mind for the future. Thanks for the review. > Reviewed-by: Andreas Färber > > Andreas > -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software