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

[Alex Bennée]

Sergey Fedorov <address@hidden> writes:

> 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>

I should add for the testing to fail without this series I had to apply
the hot-path fixes otherwise lock contention has a serialising affect on
the flushes anyway.

>>
>>
>> --
>> Alex Bennée


--
Alex Bennée