qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Claudio Fontana
Subject: Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration
Date: Tue, 10 Nov 2020 10:40:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]