From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtDaU-0002AK-Tx for qemu-devel@nongnu.org; Fri, 15 May 2015 07:15:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtDaP-0006VD-RI for qemu-devel@nongnu.org; Fri, 15 May 2015 07:15:30 -0400 Received: from cantor2.suse.de ([195.135.220.15]:50699 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtDaP-0006V3-3q for qemu-devel@nongnu.org; Fri, 15 May 2015 07:15:25 -0400 Message-ID: <5555D54A.9080000@suse.de> Date: Fri, 15 May 2015 13:15:22 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <5b1feadab1338f3b9eeba73704e7996fd096bb0c.1431583229.git.alistair.francis@xilinx.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v1 3/3] target-microblaze: Convert use-fpu to a CPU property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alistair Francis , Peter Crosthwaite Cc: Edgar Iglesias , "qemu-devel@nongnu.org Developers" Am 15.05.2015 um 08:36 schrieb Alistair Francis: > On Fri, May 15, 2015 at 4:32 PM, Peter Crosthwaite > wrote: >> On Thu, May 14, 2015 at 10:56 PM, Alistair Francis >> wrote: >>> On Fri, May 15, 2015 at 3:52 PM, Peter Crosthwaite >>> wrote: >>>> On Thu, May 14, 2015 at 10:48 PM, Alistair Francis >>>> wrote: >>>>> On Fri, May 15, 2015 at 3:22 PM, Peter Crosthwaite >>>>> wrote: >>>>>> On Wed, May 13, 2015 at 11:08 PM, Alistair Francis >>>>>> wrote: >>>>>>> | PVR2_FPU_EXC_MASK \ >>>>>>> | 0; >>>>>>> + >>>>>>> + if (cpu->cfg.usefpu) { >>>>>>> + env->pvr.regs[0] |=3D PVR0_USE_FPU_MASK; >>>>>>> + env->pvr.regs[2] |=3D PVR2_USE_FPU_MASK; >>>>>>> + >>>>>>> + if (cpu->cfg.usefpu > 1) { >>>>>>> + env->pvr.regs[2] |=3D PVR2_USE_FPU2_MASK; >>>>>>> + } >>>>>>> + } >>>>>> >>>>>> This should be handled at realize time. See pl330_realize for exam= ple >>>>>> of realize-time PVR ("cfg" in that case) population. >>>>> >>>>> But the env state gets wiped out at reset, so the information will = be lost. >>>> >>>> Ahh, so the solution there is to do what ARM does and have a section >>>> at the back of the env which survives reset. Check the memset in >>>> arm_cpu_reset. >>> >>> Ok, just to clarify we want all of the pvr registers to be preserved = on reset? >> >> yes. But something that just occured to me, does it make sense to move >> it outside the env? into the CPUState? Andreas mentioned that fields >> in the CPU state before the env can be used with negative env* offsets >> by translated code. This means the PVR could just be pushed up to >> CPUState. >=20 > Do any other machines do that? >=20 > I'm happy with leaving it in the env (partly because I just did it) > and it also matches the way that ARM does it. All targets had everything in env originally, so that's not really an argument for anything. You need to decide what makes sense for your target - icount is an example using negative offsets in CPUState now, whereas TCGv* variables declared via offset from env remained in env. If moving something to the end of env is an option, then moving it to MicroBlazeCPU (not CPUState!) would seem better, especially when it's not supposed to be reset. Going from CPUMBState *env to MicroBlazeCPU *cpu is a cheap offset operation, whereas CPUState *cs involves a QOM cas= t. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)