All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Fedorov <serge.fdrv@gmail.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Sergey Fedorov" <sergey.fedorov@linaro.org>,
	qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag
Date: Fri, 22 Apr 2016 12:49:57 +0300	[thread overview]
Message-ID: <5719F3C5.90308@gmail.com> (raw)
In-Reply-To: <87r3dytyou.fsf@linaro.org>

On 22/04/16 00:54, Alex Bennée wrote:
> Sergey Fedorov <serge.fdrv@gmail.com> writes:
>
>> On 21/04/16 19:16, Sergey Fedorov wrote:
>>> On 21/04/16 18:55, Alex Bennée wrote:
>>>> Sergey Fedorov <serge.fdrv@gmail.com> writes:
>>>>
>>>>> On 18/04/16 20:51, Sergey Fedorov wrote:
>>>>>> On 18/04/16 20:17, Alex Bennée wrote:
>>>>>>> Sergey Fedorov <serge.fdrv@gmail.com> writes:
>>>>>>>> On 18/04/16 17:09, Alex Bennée wrote:
>>>>>>>>> Sergey Fedorov <sergey.fedorov@linaro.org> 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 <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
>>>>>>>>     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.

Okay, I'll include this in the next respin.

Kind regards,
Sergey

      reply	other threads:[~2016-04-22  9:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 20:45 [Qemu-devel] [PATCH v3 0/4] tcg: Misc clean-up patches Sergey Fedorov
2016-04-14 20:45 ` [Qemu-devel] [PATCH v3 1/4] tcg: code_bitmap is not used by user-mode emulation Sergey Fedorov
2016-04-14 20:45 ` [Qemu-devel] [PATCH v3 2/4] tcg: reorganize tb_find_physical loop Sergey Fedorov
2016-04-14 20:45 ` [Qemu-devel] [PATCH v3 3/4] cpu-exec: elide more icount code if CONFIG_USER_ONLY Sergey Fedorov
2016-04-14 20:45 ` [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag Sergey Fedorov
2016-04-18 14:09   ` Alex Bennée
2016-04-18 15:05     ` Sergey Fedorov
2016-04-18 15:34       ` Peter Maydell
2016-04-18 17:17       ` Alex Bennée
2016-04-18 17:51         ` Sergey Fedorov
2016-04-21 14:35           ` Sergey Fedorov
2016-04-21 15:55             ` Alex Bennée
2016-04-21 16:16               ` Sergey Fedorov
2016-04-21 17:18                 ` Sergey Fedorov
2016-04-21 21:54                   ` Alex Bennée
2016-04-22  9:49                     ` Sergey Fedorov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5719F3C5.90308@gmail.com \
    --to=serge.fdrv@gmail.com \
    --cc=afaerber@suse.de \
    --cc=alex.bennee@linaro.org \
    --cc=crosthwaite.peter@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sergey.fedorov@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.