Emilio G. Cota <c...@braap.org> writes:
> On Thu, Nov 22, 2018 at 17:09:22 +0000, Alex Bennée wrote:
>>
>> Emilio G. Cota <c...@braap.org> 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
