From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7wiD-0000H1-L5 for qemu-devel@nongnu.org; Wed, 14 Mar 2012 18:30:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7wiB-0000Zi-Qx for qemu-devel@nongnu.org; Wed, 14 Mar 2012 18:30:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36914 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7wiB-0000Za-Hn for qemu-devel@nongnu.org; Wed, 14 Mar 2012 18:30:27 -0400 Message-ID: <4F611C00.8010004@suse.de> Date: Wed, 14 Mar 2012 23:30:24 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1330893156-26569-1-git-send-email-afaerber@suse.de> <1331398436-20761-1-git-send-email-afaerber@suse.de> <1331398436-20761-4-git-send-email-afaerber@suse.de> <4F5F4927.4090801@redhat.com> In-Reply-To: <4F5F4927.4090801@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC v4 03/20] target-arm: Embed CPUARMState in QOM ARMCPU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Peter Maydell Cc: Paul Brook , qemu-devel@nongnu.org, Anthony Liguori , Richard Henderson Am 13.03.2012 14:18, schrieb Paolo Bonzini: > Il 10/03/2012 17:53, Andreas F=C3=A4rber ha scritto: >> /** >> * ARMCPU: >> + * @env: Legacy CPU state. >> * >> * An ARM CPU core. >> */ >> @@ -58,7 +60,17 @@ typedef struct ARMCPU { >> /*< private >*/ >> CPUState parent_obj; >> /*< public >*/ >> + >> + /* TODO Inline this and split off common state */ >> + CPUARMState env; >> } ARMCPU; >> =20 >=20 > As usual I don't like "legacy". :) Well, it refers to "former CPUState of which some or many fields are going to be extracted". I wouldn't want to write it into documentation as such. " * @env: CPUARMState" is not telling either. Better wordings anyone? > A more interesting distinction is > between state that is relevant to the emulation, and state that is > relevant to the main loop or the machine. The former is reinitialized > after reset and can remain in CPUFooState. The latter is not > reinitialized after reset, can move to QOM, and in most cases that's > what we access when we use CPUArchState. Actually I was planning on keeping CPU*State only for TCG fields. Whether a field is reset or not should be determined by the reset callback, not by a semi-magic memset() up to a certain field name. That's especially problematic for cp15. The CPU*State struct stays around for two reasons, 1) allowing an incremental conversion of targets, 2) allowing offset calculations for TCG from the middle of the struct. Mentioning this, we need to review all my *CPU structs to make sure env is the *first* member and that any fields accessed by offset in its parent CPUState are placed *last*, to minimize the immediates, as previously pointed out by rth. Starts to matter once we move icount into CPUState, as done on qom-cpu-wip branch. > Also, I understand that the conversion is not fully mechanical, but > perhaps it can be made "more" mechanical than this? Splitting this > patch in two would be nice, but I can't say I read it fully. Hm, this patch has been around since v1 and so far nobody requested a particular split... it would be possible to move init and reset code in separate patches if deemed necessary? Peter? 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