Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU

[Paolo Bonzini <pbonzini@redhat.com>]

On 18/11/20 18:30, Eduardo Habkost wrote:
>> Adding a layer of indirect calls is not very different from monkey patching
>> though.
> 
> I'm a little bothered by monkey patching, but I'm more
> bothered by having to:
> 
> (1) register (module_init()) a function (kvm_cpu_accel_register()) that
>    (2) register (accel_register_call()) a function (kvm_cpu_accel_init()) that
>      (3) register (x86_cpu_accel_init()) a data structure (X86CPUAccel kvm_cpu_accel) that
>        (4) will be saved in multiple QOM classes, so that
>          (5) we will call the right X86CPUClass.accel method at the right moment
>              (common_class_init(), instance_init(), realizefn()),
> where:
>    step 4 must be done before any CPU object is created
>      (otherwise X86CPUAccel.instance_init & X86CPUAccel.realizefn
>       will be silently ignored), and
>    step 3 must be done after all QOM types were registered.
> 
>> You also have to consider that accel currently does not exist in usermode
>> emulators, so that's an issue too. I would rather get a simple change in
>> quickly, instead of designing the perfect class hierarchy.
> 
> It doesn't have to be perfect.  I agree that simple is better.
> 
> To me, registering a QOM type and looking it up when necessary is
> simpler than the above.  Even if it's a weird class having no
> object instances.  It probably could be an interface type.

Registering a QOM type still has quite some boilerplate.  Also 
registering a QOM type has a public side effect (shows up in 
qom-list-types).  In general I don't look at QOM unless I want its 
property mechanism, but maybe that's just me.

>> Perhaps another idea would be to allow adding interfaces to classes
>> *separately from the registration of the types*. Then we can use it to add
>> SOFTMMU_ACCEL and I386_ACCEL interfaces to a bare bones accel class, and
>> add the accel object to usermode emulators.
> 
> I'm not sure I follow.  What do you mean by bare bones accel
> class, and when exactly would you add the new interfaces to the
> classes?

A bare bones accel class would not have init_machine and setup_post 
methods; those would be in a TYPE_SOFTMMU_ACCEL interface.  It would 
still have properties (such as tb-size for TCG) and would be able to 
register compat properties.

Where would I add it, I don't know.  It could be a simple public wrapper 
around type_initialize_interface() if we add a new MODULE_INIT_* phase 
after QOM.

Or without adding a new phase, it could be a class_type->array of 
(interface_type, init_fn) hash table.  type_initialize would look up the 
class_type by name, add the interfaces would to the class with 
type_initialize_interface, and then call the init_fn to fill in the vtable.

Paolo