From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPAG0-0000QL-8W for qemu-devel@nongnu.org; Tue, 11 Aug 2015 10:10:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPAFt-0001er-Ml for qemu-devel@nongnu.org; Tue, 11 Aug 2015 10:10:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPAFt-0001ec-Hd for qemu-devel@nongnu.org; Tue, 11 Aug 2015 10:10:17 -0400 References: <1439220437-23957-1-git-send-email-fred.konrad@greensocs.com> <55C9EE60.80004@redhat.com> <55C9FFC0.7040502@greensocs.com> From: Paolo Bonzini Message-ID: <55CA023F.2080002@redhat.com> Date: Tue, 11 Aug 2015 16:10:07 +0200 MIME-Version: 1.0 In-Reply-To: <55C9FFC0.7040502@greensocs.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frederic Konrad , qemu-devel@nongnu.org, mttcg@greensocs.com Cc: alex.bennee@linaro.org, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, guillaume.delbergue@greensocs.com On 11/08/2015 15:59, Frederic Konrad wrote: >> - tb_lock usage in tb_find_fast is complicated and introduces the need >> for other complicated code such as the tb_invalidate callback. Instead, >> the tb locking should reuse the cpu-exec.c code for user-mode emulation, >> with additional locking in the spots identified by Fred. > > The reason for this is that locking around tb_find_fast just kills the > performance. Let's make it correct first. :) >> - the whole signal-based qemu_cpu_kick can just go away. Just setting >> tcg_exit_req and exit_request will kick the TCG thread. The hairy Win32 >> SuspendThread/ResumeThread goes away too. I suggest doing it now, >> because proving it unnecessary is easier than proving it correct. > > Just setting tcg_exit_req and exit_request and signal the cpu->halt_cond > I guess? Yes. >> - the big QEMU lock is not taken anywhere for MMIO accesses that require >> it (i.e. basically all of them) > Isn't that handled by prepare_mmio_access? That's not used on the TCG path (which calls memory_region_dispatch_read/write directly). Paolo