Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass

[Eduardo Habkost]

On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> >> add a new optional interface to CPUClass,
> >> which allows accelerators to extend the CPUClass
> >> with additional accelerator-specific initializations.
> >>
> >> Signed-off-by: Claudio Fontana <cfontana@suse.de>
> >> ---
> > [...]
> >> +static void accel_init_cpu_int_aux(ObjectClass *klass, void *opaque)
> >> +{
> >> +    CPUClass *cc = CPU_CLASS(klass);
> >> +    AccelCPUClass *accel_cpu_interface = opaque;
> >> +
> >> +    cc->accel_cpu_interface = accel_cpu_interface;
> >> +    if (accel_cpu_interface->cpu_class_init) {
> >> +        accel_cpu_interface->cpu_class_init(cc);
> >> +    }
> >> +}
> > 
> > So, now that the approach we're following to trigger the
> > accel_init_cpu*() call is less controversial (thanks for your
> > patience!), we can try to address the monkey patching issue:
> > 
> > Monkey patching classes like this is acceptable as an initial
> > solution, but I'd like us to have a plan to eventually get rid of
> > it.  Monkey patching CPU classes makes querying of CPU model
> > information less predictable and subtly dependent on QEMU
> > initialization state.
> 
> 
> The question of QEMU initialization state and the querying of supported 
> functionality, also in relationship with the loadable modules, is I think a 
> larger discussion.
> 
> Regardless of the amount of glue code and lipstick, this is hiding the fact 
> that the fundamentals of the object hierarchy for cpus are wrong,
> and are (unfortunately) codified as part of the external interface.

That's probably right, and removal of monkey patching might force
us to change our external interfaces.

> 
> 
> > 
> > Removing CPUClass.accel_cpu_interface may be easy, because it
> > should be possible to just call current_accel() when realizing
> > CPUs.  Getting rid of CPUClass.cpu_class_init might be more
> > difficult, depending on what the ->cpu_class_init() function is
> > doing.
> 
> 
> This seems to be for a next step to me.

Agreed, although I'd like to understand what makes
AccelCPUClass.cpu_class_init() so important in the first version
(considering that existing x86_cpu_class_init() has zero
tcg_enabled() calls today).

-- 
Eduardo