On Fri, Jun 29, 2018 at 05:16:52PM -0300, Eduardo Habkost wrote: > On Fri, Jun 29, 2018 at 05:18:21PM +0200, Igor Mammedov wrote: > > On Fri, 29 Jun 2018 12:14:05 +0100 > > Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > > On Fri, Jun 29, 2018 at 01:08:38PM +0200, Paolo Bonzini wrote: > > > > On 29/06/2018 13:07, Greg Kurz wrote: > > > > >>>> Also asserting current_machine != NULL is not necessary, since > > > > >>>> you're > > > > >>>> immediately dereferencing it. > > > > >>> Is there a practical way to simply initialize the accelerators > > > > >>> earlier > > > > >>> in startup sequence, so we just remove or at least reduce, the > > > > >>> liklihood > > > > >>> of accessing it too early ? > > > > >> We can try, though not for 3.0 of course. > > > > >> > > > > > FWIW, the motivation for this patch was kvm_enabled() being called > > > > > under > > > > > the class_init function of the machine TypeInfo. This happens way > > > > > earlier > > > > > than accelerator init. Not sure this is doable, but I can have a look. > > > > > > > > > > > > > Probably not, that's way too early indeed. > > > > > > Yeah, doing anything non-trivial in class_init is just asking for trouble, > > > as conceivably nothing is initialized at that point. > > isn't class_init called lazily? (so it might actually work as far as type > > isn't touched before kvm is initialized) > > You have a good point: this means class_init bugs won't always > trigger the assert because of lazy class_init. It would be a > good idea to add a functional test that calls qom-list-types > using --preconfig to try to trigger them.
Heh, I just noticed that the first thing we do immediately after parsing command-line options is calling: select_machine() find_default_machine() object_class_get_list() object_class_foreach() g_hash_table_foreach() object_class_foreach_tramp() type_initialize() ...which will call class_init for every single QOM type in QEMU. -- Eduardo