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
