[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