On 11/27/20 7:13 PM, Eduardo Habkost wrote: > 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). >
currently x86_cpu_common_class_init() has #ifdef CONFIG_TCG and #ifdef CONFIG_USER_ONLY I move this code to a tcg specific module, and I also move the parts that should have been CONFIG_TCG before but were probably just missed. Ciao, Claudio