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: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH v2] accel: forbid early use of kvm_enabled() and friends
Date: Fri, 29 Jun 2018 13:42:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

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.  



reply via email to

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