qemu-devel
[Top][All Lists]
Advanced

[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: Sergey Fedorov
Subject: Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag
Date: Thu, 21 Apr 2016 20:18:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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?

Kind regards,
Sergey



reply via email to

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