From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:35791)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1QvV3J-00030P-0M
	for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:00:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1QvV39-0002Gm-M5
	for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:00:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59403)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1QvV39-0002Ga-BH
	for qemu-devel@nongnu.org; Mon, 22 Aug 2011 10:00:23 -0400
Message-ID: <4E5260E9.9030603@redhat.com>
Date: Mon, 22 Aug 2011 16:00:09 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1314019498-8550-1-git-send-email-aliguori@us.ibm.com>
	<CAFEAcA9xcWBXJxi+K9OkdqGXogBhxSO6TgFekV7fzkv-wtoXJA@mail.gmail.com>
In-Reply-To: <CAFEAcA9xcWBXJxi+K9OkdqGXogBhxSO6TgFekV7fzkv-wtoXJA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Blue Swirl <blauwirbel@gmail.com>, Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>

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.

Paolo