From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHArC-0000T2-Dh for qemu-devel@nongnu.org; Wed, 04 Sep 2013 07:02:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHAr5-0002nI-3r for qemu-devel@nongnu.org; Wed, 04 Sep 2013 07:02:42 -0400 Message-ID: <52271345.4050603@suse.de> Date: Wed, 04 Sep 2013 13:02:29 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1378285521-3230-1-git-send-email-afaerber@suse.de> <1378285521-3230-4-git-send-email-afaerber@suse.de> <52270ABA.7090102@redhat.com> In-Reply-To: <52270ABA.7090102@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() into a CPUClass hook List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Peter Crosthwaite , Jia Liu , Anthony Green , qemu-devel@nongnu.org, Alexander Graf , Blue Swirl , Max Filippov , Michael Walle , qemu-ppc , "Edgar E. Iglesias" , Guan Xuetao , Aurelien Jarno , Richard Henderson Am 04.09.2013 12:26, schrieb Paolo Bonzini: > Il 04/09/2013 11:04, Andreas F=C3=A4rber ha scritto: >> static inline TranslationBlock *tb_find_fast(CPUArchState *env) >> { >> + CPUState *cpu =3D ENV_GET_CPU(env); >> + CPUClass *cc =3D CPU_GET_CLASS(cpu); >> TranslationBlock *tb; >> - target_ulong cs_base, pc; >> + vaddr cs_base, pc; >> int flags; >> =20 >> /* we record a subset of the CPU state. It will >> always be the same before a given translated block >> is executed. */ >> - cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); >> + cc->get_tb_cpu_state(cpu, &pc, &cs_base, &flags); >=20 > I'm afraid you cannot turn inline functions into indirect calls like > this in hot paths. >=20 > One alternative would be to hoist the function call to the beginning of > cpu_exec, and ensure that any place that modifies the result calls > cpu_exit. It may be a problem for SPARC's npc stuff, for which I have > no idea how it works. Sorry, you lost me here... > Another is to change cpu-exec.c into a file that is #included by > target-*/helper.c or something like that. This way cpu-exec.c can stil= l > use the inline functions. I don't see how that would help with compiling multiple CPU types into one executable. A common CPU struct type is needed to compile the core CPU code once, which in turn requires dispatching for target-specific bits, such as this one or previously gdbstub and TBD monitor. Combining only targets with target_ulong of the same size and identical endianness is a restriction we can accept, I think - examples include 32-bit ARM+SH4A, ARM+MicroBlaze, ARM+Hexagon, ARM+Epiphany. For performance reasons I have been careful not to have an, e.g., cpu_get_tb_cpu_state() wrapper that calls CPU_GET_CLASS() each time. Many of the "cpu" variables added are being cleaned up later in the series by argument propagation. And in placement of variables requiring CPU() cast I have been careful to place them depending on where they are/will be actually used rather than always placing them at the top. But if behavior depends on the CPU type, then it cannot be a global function - cpu.h as-is is a problem and needs to be broken up. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg