From: "Andreas Färber" <andreas.faerber@web.de>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/3] target-mips:enabling of 64 bit user mode and floating point operations MIPS_HFLAG_UX is included in env->hflags so that the address computation for LD instruction does not treated as 32 bit code see gen_op_addr_add() in t
Date: Fri, 30 Dec 2011 13:39:34 +0100 [thread overview]
Message-ID: <4EFDB106.50805@web.de> (raw)
In-Reply-To: <CAAoJSP7H63RLSj5F-aj9_oUtCPc_q7g5iLTgUW_danU-4M4icw@mail.gmail.com>
[cc'ing list]
Am 30.12.2011 08:52, schrieb Khansa Butt:
> On Thu, Dec 29, 2011 at 4:17 PM, Andreas Färber <andreas.faerber@web.de> wrote:
>> Also, given your observation, does it even make sense for
>> cpu_mips_init() to call fpu_init() when all CPUState members it
>> initializes get cleared in cpu_reset()? Maybe just move that call into
>> cpu_reset() and rename it to fpu_reset()? mmu_init() and mvp_init() seem
>> okay by contrast.
>
> why cpu_reset() calls memset? it does not reset all the members of CPUState only
> those which are in the range of offsetof(CPUMIPSState, breakpoints).
> what if I remove
> memset line?
I agree that the memset() line is bad as-is. My suggestion on some other
threads about having multiple CPUStates and/or ARM reset was to at least
define a macro than to copy this knowledge everywhere. QOM may help to
improve that in the future with better Object Orientation.
Today, the convention is that all struct members before 'breakpoints'
are zeroed on reset. Things that come after 'CPU_COMMON' are therefore
not reset. Things before CPU_COMMON, like in your case, need to be saved
before the memset() and restored afterwards (if their value is to be
preserved over reset) or initialized to some value (if different from zero).
I would strongly suggest to live with memset() for now as it's already
quite complicated to get *anything* done on mips as you've noticed. :)
Regards,
Andreas
next prev parent reply other threads:[~2011-12-30 12:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 7:55 [Qemu-devel] [PATCH 2/3] target-mips:enabling of 64 bit user mode and floating point operations MIPS_HFLAG_UX is included in env->hflags so that the address computation for LD instruction does not treated as 32 bit code see gen_op_addr_add() in t Khansa Butt
2011-12-29 11:17 ` Andreas Färber
[not found] ` <CAAoJSP5wPz_rL9x0ZZBZJz1A9RuGhohLKSg_nChyo96mvuJ70w@mail.gmail.com>
2011-12-30 7:52 ` Khansa Butt
2011-12-30 12:39 ` Andreas Färber [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-12-29 8:06 Khansa Butt
[not found] <CAAoJSP677G-bsiZ3W=D_O5DiwyKv=XtEWgU_6wH2LztGBK2s8A@mail.gmail.com>
2011-12-31 11:54 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EFDB106.50805@web.de \
--to=andreas.faerber@web.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).