qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] accel: forbid early use of kvm_enabled() and


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH v2] accel: forbid early use of kvm_enabled() and friends
Date: Fri, 29 Jun 2018 16:19:58 +0100
User-agent: Mutt/1.10.0 (2018-05-17)

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é <address@hidden> 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)

Yes, but I don't think anything should rely on it being lazy, as such an
assumption is liable to break any time code is refactored, subtley changing
class init ordering.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]