On 06/29/2018 01:14 PM, Daniel P. Berrangé 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.
May be we should consider having a set of binaries for each accelerator, KVM, TCG, etc. That would simplify a lot of the init path of the machines and also of some of the models which are trying to initialize in one mode or the other. Hybrid machines would still be possible, like using KVM for the CPUs and an emulated model for some device. But the definitions would be static, not guessed from what is available or not. C.
