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
