Alexander Graf wrote:
> On 22.06.2010, at 00:13, Jan Kiszka wrote:
>
>> Jan Kiszka wrote:
>>> And there is some race that cause a lock up in qemu_mutex_lock_iothread
>>> after a while (the cpu_unlink_tb seems to race with the linking - just a
>>> guess so far).
>> This seems to fix a long-standing race between cpu_exec and
>> signal-driven cpu_unlink_tb:
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index 026980a..bfc34e4 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -599,8 +598,9 @@ int cpu_exec(CPUState *env1)
>> TB, but before it is linked into a potentially
>> infinite loop and becomes env->current_tb. Avoid
>> starting execution if there is a pending interrupt. */
>> - if (!unlikely (env->exit_request)) {
>> - env->current_tb = tb;
>> + env->current_tb = tb;
>> + asm("");
>
> This is just barrier(), no?
> Yes, thoughtlessly copied from other places in cpu-exec.c. Guess it's time to define this properly in qemu-barriers.h, also clobbering "memory". Jan
signature.asc
Description: OpenPGP digital signature
