Re: [Qemu-devel] [PATCH RFC v4 03/20] target-arm: Embed CPUARMState in QOM ARMCPU

[Andreas Färber]

Am 13.03.2012 14:18, schrieb Paolo Bonzini:
> Il 10/03/2012 17:53, Andreas Färber 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;
>>  
> 
> 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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg