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 <cfont...@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