From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvVAv-0005ZL-1l for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:08:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvVAt-0004AO-Re for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:08:24 -0400 Received: from david.siemens.de ([192.35.17.14]:18333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvVAt-0004A6-IS for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:08:23 -0400 Message-ID: <4E5262CE.40703@siemens.com> Date: Mon, 22 Aug 2011 16:08:14 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1314019498-8550-1-git-send-email-aliguori@us.ibm.com> <4E5260E9.9030603@redhat.com> In-Reply-To: <4E5260E9.9030603@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Blue Swirl , Peter Maydell , Anthony Liguori , "qemu-devel@nongnu.org" , Aurelien Jarno On 2011-08-22 16:00, Paolo Bonzini wrote: > On 08/22/2011 03:50 PM, Peter Maydell wrote: >>> Enabling the I/O thread by default seems like an important part of declaring >>> 1.0. Besides allowing true SMP support with KVM, the I/O thread means that the >>> TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which >>> currently requires a (racey) signal based alarm system. >> >> Even with iothread it's still signal based (and still racy) -- the only way >> to get a thread currently executing TCG code to stop doing so is to send it >> a signal. > > It's signal-based, but I'm not sure it's racy when single-threaded. This: > > /* ... tb_add_jump ... */ > barrier(); > if (likely(!env->exit_request)) { > > in cpu_exec, vs. this in the signal handler: > > void cpu_exit(CPUState *env) > { > env->exit_request = 1; > cpu_unlink_tb(env); > } > > together will make sure that only a single basic block is executed after > an exit request. > > The problems with user-level emulation arise from multiple threads > concurrently execute the tb_add_jump or cpu_unlink_tb operations. My > knowledge of user-level emulation is approximately zero, but I think it > should be possible to make the race outcome predictable. That's because > (1) cpu_unlink_tb is idempotent; (2) you don't really need to do > anything in cpu_unlink_tb if the other thread is running tb_add_jump, > because setting env->exit_request will avoid entering the CPU. Current multi-threaded user mode emulation is just (too) optimistically designed. But once VCPUs start to use their own TBs and/or TB chains (maybe it can be beneficial to decouple the translation buffer from the linking), this problem should go away. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux