From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDt1m-0003lv-IS for qemu-devel@nongnu.org; Tue, 18 Sep 2012 04:19:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDt1i-00063G-En for qemu-devel@nongnu.org; Tue, 18 Sep 2012 04:19:30 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:41443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDt1i-000634-8X for qemu-devel@nongnu.org; Tue, 18 Sep 2012 04:19:26 -0400 Received: by pbbrp12 with SMTP id rp12so11165634pbb.4 for ; Tue, 18 Sep 2012 01:19:25 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <50582E86.3060206@redhat.com> Date: Tue, 18 Sep 2012 10:19:18 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Doubts on SMP, VCPU and CONFIG_IOTHREAD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Barcelo Cc: qemu-devel Il 18/09/2012 08:27, Alex Barcelo ha scritto: > > I saw some things[1] about multiple vcpu, smp and things like that. It > seemed to me that --enable-io-thread enables it. iothread means that the QEMU main thread only services an event loop (I/O, bottom halves, timers, etc.). Running CPUs is offloaded to extra threads. The iothread most of the times runs without the big QEMU lock (because most of the time it is waiting on a select system call). > But, it only works > for KVM, doesn't it? I assume that there is NOT one thread per vcpu in > TCG mode. Yes, KVM has a thread per VCPU. This is possible because with KVM the VCPU thread is _also_ running most of the time without the big QEMU lock (it is in the KVM_RUN ioctl). However, TCG needs to run with the big QEMU lock. For this reason TCG has a single thread that runs in lockstep with the io-thread. Whenever the iothread gets out of the select system call and needs the lock, it asks the TCG thread to exit and the TCG thread obeys. This is done using a condition variable qemu_io_proceeded_cond, controlled by a boolean variable iothread_requesting_mutex. Whenever the iothread goes back to sleep, it signals the condition variable and the TCG thread starts running again. > And this --enable-io-thread now is the default? This option > is always active? Now I was wondering if something "parallel" is done > in TCG (maybe through coroutines?). The lockstep behavior obtained with the condition variable is what you are looking for. Paolo