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

[Jan Kiszka]

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