Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread

[Paolo Bonzini <pbonzini@redhat.com>]

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