[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag |
Date: |
Thu, 21 Apr 2016 22:54:41 +0100 |
User-agent: |
mu4e 0.9.17; emacs 25.0.92.6 |
Sergey Fedorov <address@hidden> writes:
> On 21/04/16 19:16, Sergey Fedorov wrote:
>> On 21/04/16 18:55, Alex Bennée wrote:
>>> Sergey Fedorov <address@hidden> writes:
>>>
>>>> On 18/04/16 20:51, Sergey Fedorov wrote:
>>>>> On 18/04/16 20:17, Alex Bennée wrote:
>>>>>> Sergey Fedorov <address@hidden> writes:
>>>>>>> On 18/04/16 17:09, Alex Bennée wrote:
>>>>>>>> Sergey Fedorov <address@hidden> writes:
>>>>>>>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>>>>>> (snip)
>>>>>>>>> @@ -507,14 +510,12 @@ int cpu_exec(CPUState *cpu)
>>>>>>>>> }
>>>>>>>>> tb_lock();
>>>>>>>>> tb = tb_find_fast(cpu);
>>>>>>>>> - /* Note: we do it here to avoid a gcc bug on Mac OS
>>>>>>>>> X when
>>>>>>>>> - doing it in tb_find_slow */
>>>>>>>> Is this still true? Would it make more sense to push the patching down
>>>>>>>> to the gen_code?
>>>>>>> This comment comes up to the commit:
>>>>>>>
>>>>>>> commit 1538800276aa7228d74f9d00bf275f54dc9e9b43
>>>>>>> Author: bellard <address@hidden>
>>>>>>> Date: Mon Dec 19 01:42:32 2005 +0000
>>>>>>>
>>>>>>> workaround for gcc bug on PowerPC
>>>>>>>
>>>>>>>
>>>>>>> It was added more than ten years ago. Anyway, now this code is here not
>>>>>>> because of the bug: we need to reset 'next_tb' which is a local variable
>>>>>>> in cpu_exec(). Personally, I don't think it would be neater to hide it
>>>>>>> into gen_code(). Do you have some thoughts on how we could benefit from
>>>>>>> doing so? BTW, I had a feeling that it may be useful to reorganize
>>>>>>> cpu_exec() a bit, although I don't have a solid idea of how to do this
>>>>>>> so far.
>>>>>> I'm mainly eyeing the tb_lock/unlock which would be nice to push further
>>>>>> down the call chain if we can, especially if the need to lock
>>>>>> tb_find_fast can be removed later on.
>>>>> Yes, it would be nice to possibly have all tb_lock/unlock() calls (or at
>>>>> least their pairs) in the same block. There is a lot to be thought over :)
>>>> It's not so simple because tb_find_fast() is also called in replay mode
>>>> to find a TB for cpu_exec_nocache()... I'm not sure it's worth touching
>>>> it now.
>>> If the locking is pushed into tb_find_fast or further down is this an
>>> issue?
>> We would have to pass 'next_tb' (or 'last_tb' and 'tb_exit' after
>> cleaning it up) if we move TB chaining code to tb_find_fast(). But
>> tb_find_fast() is also called in replay mode to find a TB for
>> cpu_exec_nocache() where we don't bother with TB chaining... Do you
>> think it would be fine to make those changes?
>
> Are you thinking about something like this:
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 1d12e8bc2739..07e9ede49193 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -320,7 +320,9 @@ found:
> return tb;
> }
>
> -static inline TranslationBlock *tb_find_fast(CPUState *cpu)
> +static inline TranslationBlock *tb_find_fast(CPUState *cpu,
> + TranslationBlock **last_tb,
> + int tb_exit)
> {
> CPUArchState *env = (CPUArchState *)cpu->env_ptr;
> TranslationBlock *tb;
> @@ -331,11 +333,27 @@ static inline TranslationBlock
> *tb_find_fast(CPUState *cpu)
> always be the same before a given translated block
> is executed. */
> cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags);
> + tb_lock();
> tb = cpu->tb_jmp_cache[tb_jmp_cache_hash_func(pc)];
> if (unlikely(!tb || tb->pc != pc || tb->cs_base != cs_base ||
> tb->flags != flags)) {
> tb = tb_find_slow(cpu, pc, cs_base, flags);
> }
> + if (cpu->tb_flushed) {
> + /* Ensure that no TB jump will be modified as the
> + * translation buffer has been flushed.
> + */
> + *last_tb = NULL;
> + cpu->tb_flushed = false;
> + }
> + /* see if we can patch the calling TB. When the TB
> + spans two pages, we cannot safely do a direct
> + jump. */
> + if (*last_tb != NULL && tb->page_addr[1] == -1
> + && !qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) {
> + tb_add_jump(*last_tb, tb_exit, tb);
> + }
> + tb_unlock();
> return tb;
> }
>
> @@ -441,7 +459,8 @@ int cpu_exec(CPUState *cpu)
> } else if (replay_has_exception()
> && cpu->icount_decr.u16.low + cpu->icount_extra
> == 0) {
> /* try to cause an exception pending in the log */
> - cpu_exec_nocache(cpu, 1, tb_find_fast(cpu), true);
> + last_tb = NULL; /* Avoid chaining TBs */
> + cpu_exec_nocache(cpu, 1, tb_find_fast(cpu, &last_tb,
> 0), true);
> ret = -1;
> break;
> #endif
> @@ -511,23 +530,7 @@ int cpu_exec(CPUState *cpu)
> cpu->exception_index = EXCP_INTERRUPT;
> cpu_loop_exit(cpu);
> }
> - tb_lock();
> - tb = tb_find_fast(cpu);
> - if (cpu->tb_flushed) {
> - /* Ensure that no TB jump will be modified as the
> - * translation buffer has been flushed.
> - */
> - last_tb = NULL;
> - cpu->tb_flushed = false;
> - }
> - /* see if we can patch the calling TB. When the TB
> - spans two pages, we cannot safely do a direct
> - jump. */
> - if (last_tb != NULL && tb->page_addr[1] == -1
> - && !qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) {
> - tb_add_jump(last_tb, tb_exit, tb);
> - }
> - tb_unlock();
> + tb = tb_find_fast(cpu, &last_tb, tb_exit);
> if (likely(!cpu->exit_request)) {
> uintptr_t ret;
> trace_exec_tb(tb, tb->pc);
>
> ... right?
Yeah that sort of thing.
>
> Kind regards,
> Sergey
--
Alex Bennée
- [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, (continued)
- [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/14
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Peter Maydell, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag,
Alex Bennée <=
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/22