Re: arm_cpu_post_init (Was: Re: arm: "max" CPU class hierarchy changes possible?)

[Claudio Fontana]

On 3/18/21 2:10 PM, Eduardo Habkost wrote:
> On Thu, Mar 18, 2021 at 01:59:08PM +0100, Andrew Jones wrote:
>> On Thu, Mar 18, 2021 at 01:42:36PM +0100, Claudio Fontana wrote:
>>> On 3/18/21 1:08 PM, Andrew Jones wrote:
>>>> On Thu, Mar 18, 2021 at 12:32:30PM +0100, Claudio Fontana wrote:
>>>>> And why do we have a separate arm_cpu_finalize_features()?
>>>>
>>>> Separate, because it's not just called from arm_cpu_realizefn().
>>>
>>> In particular it is also called by the monitor.c in 
>>> qmp_query_cpu_model_expansion(),
>>>
>>> which basically creates an object of the cpu subclass,
>>> and then calls arm_cpu_finalize_[features]() explicitly on the object.
>>>
>>> Is the qdev realize() method not called in this case? Should instead it be 
>>> triggered, rather than initializing/realizing an incomplete object?
>>
>> Can you elaborate on what you mean by "triggered"? The QMP query does the
>> least that it can get away with while still reusing the CPU model's
>> feature initialization code. Any suggestions for improving that,
>> preferably in the form of a patch, would be welcome. If it works well for
>> Arm, then it could probably be applied to other architectures. The Arm QMP
>> query is modeled off the others.
> 
> This sound very similar to x86_cpu_expand_features(), so the
> approach makes sense to me.

Interesting, to me it sounds like a CPUClass method is hiding here, 
cc->cpu_expand_features(),
I could help kickstart the implementation but would need a good description / 
comment of exactly which features are supposed to be expanded there. 

> 
> It wouldn't make sense to call realize() inside
> qmp_query_cpu_model_expansion().  Realizing the CPU means
> plugging it into the guest, and we would never want to do that
> when executing a query command.
> 

Makes sense, thanks for the explanation.

Ciao,

Claudio