qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 10/48] exec: export do_tb_flush


From: Alex Bennée
Subject: Re: [Qemu-devel] [RFC 10/48] exec: export do_tb_flush
Date: Mon, 26 Nov 2018 11:11:53 +0000
User-agent: mu4e 1.1.0; emacs 26.1.90

Emilio G. Cota <address@hidden> writes:

> On Thu, Nov 22, 2018 at 17:09:22 +0000, Alex Bennée wrote:
>>
>> Emilio G. Cota <address@hidden> writes:
>>
>> > This will be used by plugin code to flush the code cache as well
>> > as doing other bookkeeping in a safe work environment.
>>
>> This seems a little excessive given the plugin code could just call
>> tb_flush() directly. Wouldn't calling tb_flush after scheduling the
>> plugin_destroy be enough?
>>
>> If there is a race condition here maybe we could build some sort of
>> awareness into tb_flush as to the current run state. But having two
>> entry points to this rather fundamental action seems likely to either be
>> misused or misunderstood.
>
> We have to make sure that no callback left in the generated code is
> called once a plugin has been uninstalled. To me, using the same safe
> work window to both flush the TB and uninstall the plugin seems the
> simplest way to do this.

I still think making tb_flush() aware that it can run in an exclusive
period would be a better solution than exposing two functions for the
operation. So tb_flush could be something like:

  void tb_flush(CPUState *cpu)
  {
      if (tcg_enabled()) {
          unsigned tb_flush_count = atomic_mb_read(&tb_ctx.tb_flush_count);
          if (cpu_current_and_exclusive(cpu)) {
              do_tb_flush(RUN_ON_CPU_HOST_INT(tb_flush_count))
          } else {
              async_safe_run_on_cpu(cpu, do_tb_flush,
                                    RUN_ON_CPU_HOST_INT(tb_flush_count));
          }
      }
  }

Or possibly push that logic down into async_safe_run_on_cpu()?

--
Alex Bennée



reply via email to

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