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

[Eduardo Habkost]

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.

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.

-- 
Eduardo