From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3ipW-0002Im-5S for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:24:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3ipV-0006i3-36 for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:24:50 -0400 Received: from david.siemens.de ([192.35.17.14]:27916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3ipU-0006hv-Px for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:24:49 -0400 Message-ID: <503337B6.4070408@siemens.com> Date: Tue, 21 Aug 2012 09:24:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <50327DD8.8070205@siemens.com> <50333245.3060501@redhat.com> In-Reply-To: <50333245.3060501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Drop redundant resume_all_vcpus from main List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Marcelo Tosatti , qemu-devel , Avi Kivity 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 >> --- >> >> 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