Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration

[Claudio Fontana <cfontana@suse.de>]

On 11/9/20 7:03 PM, Daniel P. Berrangé wrote:
> On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
>> split cpu.c into:
>>
>> cpu.c            cpuid and common x86 cpu functionality
>> host-cpu.c       host x86 cpu functions and "host" cpu type
>> kvm-cpu-type.c   KVM x86 cpu type
>> hvf-cpu-type.c   HVF x86 cpu type
>> tcg-cpu-type.c   TCG x86 cpu type
>>
>> Defer the x86 models registration to MODULE_INIT_ACCEL_CPU,
>> so that accel-specific types can be used as parent types for all
>> cpu models. Use the generic TYPE_X86_CPU only if no
>> accel-specific specialization is enabled.
> 
> Can you give more info on why this is needed and/or desirable ?

Hello Daniel, there is a pointer to the overall higher level motivation in the cover letter.

But I am not pushing for this specific mechanism to be used, as mentioned in the cover letter.

If we need another mechanism to achieve that (not delaying the x86 model registration and make them inherit from the specialized class), but something else,
I would be happy to get additional ideas.

> 
> Dynamically changing the class hierarchy of CPUs at runtime feels
> like a rather suspicious approach to me

TYPE_X86_CPU is base type is registered as usual.
New accel-specialized types are defined (TYPE_TCG_CPU, TYPE_KVM_CPU, TYPE_HVF_CPU), also using normal type registration.

The missing step is how to adapt all the cpu models to use the functionality.

The accelerator that is finally chosen to be used is only known at a specific point in the qemu initialization.
This point of time I defined as MODULE_INIT_ACCEL_CPU.

That is the time when we know how the CPU should actually really behave (how it should be realized, etc).

In this series I realized this by registering the cpu models only at MODULE_INIT_ACCEL_CPU time, and not earlier.
But maybe there is a better idea on how to do it, and I am all ears.

.
> 
> It is contrary to work we've been doing recently to try to make all
> classes be fully statically defined by getting rid of dynamic properties,
> such that introspection of classes does not depend on other CLI flags
> you might have passed.

Understood, this goes against other requirements.

The dynamism introduced here is to register the cpu models at MODULE_INIT_ACCEL_CPU time instead of MODULE_INIT_QOM time.
As a result, for any chosen accelerator, the type tree and class tree is identical.

So maybe there is a way to leverage this to accommodate both needs?

> 
> 
> Regards,
> Daniel
>