qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Drop redundant resume_all_vcpus from main


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] Drop redundant resume_all_vcpus from main
Date: Tue, 21 Aug 2012 09:24:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-08-21 09:01, Paolo Bonzini wrote:
> Il 20/08/2012 20:11, Jan Kiszka ha scritto:
>> VCPUs are either resumed directly via vm_start, after the incoming
>> migration is done, or when a continue command is issued. We don't need
>> the explicit resume before entering main_loop.
>>
>> Signed-off-by: Jan Kiszka <address@hidden>
>> ---
>>
>> I was adding nesting support to pause/resume_all_vcpus, and that
>> stumbled over the imbalance below.
>>
>>  vl.c |    1 -
>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index ebee867..231d3ab 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
>>  
>>      os_setup_post();
>>  
>> -    resume_all_vcpus();
>>      main_loop();
>>      bdrv_close_all();
>>      pause_all_vcpus();
>>
> 
> Makes sense.  Do we need a "main loop and similar" tree, or can that
> tree be just uq/master now that qemu-kvm.c is dying?

I'm not sure if this qualifies for uq/master. On the other hand, all the
efforts to refactor locking and make QEMU more scalable would like be
happy to have a home. Can be uq/master, but they will not only affect
KVM in the end.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

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