From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvaxr-0001R7-V2 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:19:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvaxq-0001R1-Pj for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:19:19 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:50557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvaxq-0001Pc-K7 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:19:18 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7MKIqKi015785 for ; Mon, 22 Aug 2011 14:18:52 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7MKIqZo168330 for ; Mon, 22 Aug 2011 14:18:52 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7MEIpsG018031 for ; Mon, 22 Aug 2011 08:18:51 -0600 Message-ID: <4E52B9AA.5010405@us.ibm.com> Date: Mon, 22 Aug 2011 15:18:50 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E5279F3.7070103@siemens.com> <4E52815F.6010607@redhat.com> <4E52854D.5040805@siemens.com> In-Reply-To: <4E52854D.5040805@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] Replace qemu_system_cond with VCPU stop mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , Avi Kivity , Gleb Natapov , qemu-devel On 08/22/2011 11:35 AM, Jan Kiszka wrote: > On 2011-08-22 18:18, Avi Kivity wrote: >> On 08/22/2011 06:46 PM, Jan Kiszka wrote: >>> We can express the VCPU thread wakeup with the stop mechanism, saving >>> both qemu_system_ready and the qemu_system_cond. For KVM threads, we can >>> just enter the main loop as long as the thread is stopped. The central >>> TCG thread is better held back before the loop as there can be side >>> effects of the services called even when all CPUs are stopped. >>> >>> Creating VCPUs in stopped state will also be required for proper CPU >>> hotplugging support. >>> >>> >>> - /* and wait for machine initialization */ >>> - while (!qemu_system_ready) { >>> - qemu_cond_wait(&qemu_system_cond,&qemu_global_mutex); >>> + /* wait for initial kick-off after machine start */ >>> + while (!first_cpu->stopped) { >>> + qemu_cond_wait(tcg_halt_cond,&qemu_global_mutex); >>> } >> >> Seems inverted - do we want to wait until first_cpu is stopped, or while >> first_cpu is stopped? > > Oops, fixed below. > >> >> Do we want to process run_on_cpu() events after the machine is created >> but before a cpu is started (if starting with -S)? > > -S affects vm_running, not stopped states of individual VCPUs. So they > will get kicked off on main_loop entry, but then stop again due to > vm_running == 0. > > Jan > > -------8<-------- > > We can express the VCPU thread wakeup with the stop mechanism, saving > both qemu_system_ready and the qemu_system_cond. For KVM threads, we can > just enter the main loop as long as the thread is stopped. The central > TCG thread is better held back before the loop as there can be side > effects of the services called even when all CPUs are stopped. > > Creating VCPUs in stopped state will also be required for proper CPU > hotplugging support. > > Signed-off-by: Jan Kiszka Applied. Thanks. Regards, Anthony Liguori