qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v2 11/11] tcg: Make tb_flush() thread safe


From: Sergey Fedorov
Subject: Re: [Qemu-devel] [RFC v2 11/11] tcg: Make tb_flush() thread safe
Date: Thu, 14 Jul 2016 11:54:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 14/07/16 11:41, Alex Bennée wrote:
> Sergey Fedorov <address@hidden> writes:
>
>> From: Sergey Fedorov <address@hidden>
>>
>> Use async_safe_run_on_cpu() to make tb_flush() thread safe.
>>
>> Signed-off-by: Sergey Fedorov <address@hidden>
>> Signed-off-by: Sergey Fedorov <address@hidden>
>> ---
>>
>> Changes in v2:
>>  - stale comment about unsafe tb_flush() removed
>> ---
>>  translate-all.c | 13 ++++++++-----
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/translate-all.c b/translate-all.c
>> index eaa95e4cd7dc..e69b5d4e889e 100644
>> --- a/translate-all.c
>> +++ b/translate-all.c
>> @@ -831,8 +831,7 @@ static void page_flush_tb(void)
>>  }
>>
>>  /* flush all the translation blocks */
>> -/* XXX: tb_flush is currently not thread safe */
>> -void tb_flush(CPUState *cpu)
>> +static void do_tb_flush(CPUState *cpu, void *data)
>>  {
>>  #if defined(DEBUG_FLUSH)
>>      printf("qemu: flush code_size=%ld nb_tbs=%d avg_tb_size=%ld\n",
>> @@ -861,6 +860,11 @@ void tb_flush(CPUState *cpu)
>>      tcg_ctx.tb_ctx.tb_flush_count++;
>>  }
>>
>> +void tb_flush(CPUState *cpu)
>> +{
>> +    async_safe_run_on_cpu(cpu, do_tb_flush, NULL);
>> +}
>> +
>>  #ifdef DEBUG_TB_CHECK
>>
>>  static void
>> @@ -1163,9 +1167,8 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
>>   buffer_overflow:
>>          /* flush must be done */
>>          tb_flush(cpu);
>> -        /* cannot fail at this point */
>> -        tb = tb_alloc(pc);
>> -        assert(tb != NULL);
>> +        mmap_unlock();
>> +        cpu_loop_exit(cpu);
> Given our other discussions about lock resetting I wonder if this is
> another case where mmap_reset() could be called on cpu_loop_exit?

As I can see, this is the only place mmap_unlock() have to be called
right before cpu_loop_exit(). As I remember, all the other cased in
user-mode emulation were restructured by Peter M. in his syscall/signal
handling series. However, I like the idea to ensure that 'mmap_lock' is
released on any cpu_loop_exit(). What do maintainers think?

Kind regards,
Sergey

>
>>      }
>>
>>      gen_code_buf = tcg_ctx.code_gen_ptr;
> Otherwise so far the testing is looking pretty positive in linux-user:
>
> Tested-by: Alex Bennée <address@hidden>
> Reviewed-by: Alex Bennée <address@hidden>
>
>
> --
> Alex Bennée




reply via email to

[Prev in Thread] Current Thread [Next in Thread]