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
