From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvXuj-0006To-WB for qemu-devel@nongnu.org; Sat, 06 Jul 2013 15:13:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UvXui-00064n-Uz for qemu-devel@nongnu.org; Sat, 06 Jul 2013 15:12:57 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35070 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvXui-00064b-KM for qemu-devel@nongnu.org; Sat, 06 Jul 2013 15:12:56 -0400 Message-ID: <51D86C31.1050901@suse.de> Date: Sat, 06 Jul 2013 21:12:49 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1372536117-28167-1-git-send-email-afaerber@suse.de> <1372536117-28167-40-git-send-email-afaerber@suse.de> <51D813DC.2050400@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC qom-cpu 39/41] target-xtensa: Introduce XtensaCPU subclasses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Filippov Cc: jan.kiszka@web.de, qemu-devel@nongnu.org Am 06.07.2013 20:39, schrieb Max Filippov: > On Sat, Jul 6, 2013 at 10:01 PM, Max Filippov wrot= e: >> On Sat, Jul 6, 2013 at 4:55 PM, Andreas F=C3=A4rber = wrote: >>> Am 29.06.2013 22:01, schrieb Andreas F=C3=A4rber: >>>> Register a CPU type per core registered. Save the XtensaConfig in >>>> XtensaCPUClass instead of CPUXtensaState. >>>> >>>> Prepares for storing per-class GDB register count. >>>> >>>> Signed-off-by: Andreas F=C3=A4rber >>> >>> Ping! Can you ack? (It did not seem to break your test image.) >> >> Hi Andreas, >> >> I tried make check -C tests/tcg/xtensa with the branch you recommended >> and it segfaults on elf loading >=20 > ...and maybe a stupid question, but why moving configuration pointer aw= ay > from env and then changing every place that used to access it? Xtensa is the only target trying to implicitly access an "env" variable through a macro to obtain the number of registers for gdbstub. That's what I'm trying to fix with 40/41 in order to get rid of the #ifdeffery. The number of registers is not accessed by TCG, so it could go into XtensaCPU instead of CPUXtensaState. Further it does not change during vCPU runtime, so it no longer belongs in CPUXtensaState nor XtensaCPU but in XtensaCPUClass, which is shared among CPU cores and can be accessed statically. However we only had one XtensaCPUClass but multiple XtensaConfigs. Therefore this patch registers one XtensaCPUClass per XtensaConfig. You might remember that I once tried to place the XtensaConfig fields directly into XtensaCPUClass but that didn't work out nicely back then. This is by comparison a slim/minimal conversion to subclasses, leaving XtensaConfig and your custom registration mechanisms in place. Cleaning that up to use type_init() and type_register_static() in the respective source files and changing -cpu ? to iterate QOM types would be a nice follow-up, but not needed for this gdbstub refactoring series. Another background is that I'm trying to get rid of cpu_init() and anything that blocks using -device or device_add with QOM CPUs. Regards, 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