[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] tcg: reworking tb_invalidated_flag
From: |
Sergey Fedorov |
Subject: |
Re: [Qemu-devel] tcg: reworking tb_invalidated_flag |
Date: |
Thu, 31 Mar 2016 17:06:51 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 31/03/16 16:37, Alex Bennée wrote:
> Sergey Fedorov <address@hidden> writes:
>> Looks like no matter which approach we use, it's ultimately necessary to
>> ensure all CPUs have exited from translated code before the translation
>> buffer may be safely flushed.
> One approach would be to have multiple translation contexts with their
> own buffers and then you can safely flush TBs if no vCPUs are currently
> executing in those regions. But I suspect that is a much more complex
> future optimisation.
Yes, this is much more complex and its performance impact should be
investigated.
> Having said that is it safe to flush TBs from a given page if we know
> no vCPUs are currently executing in that page? As the execution loop has
> to exit the chained TBs as we cross page boundaries we could just keep
> account of which vCPUs are currently in which page.
It should be safe to invalidate a TB while some other CPU is executing
its translated code. But it should be guaranteed that no CPU execute any
old TB after tb_flush() since we're going to start reusing those TBs.
I see how TB cannot be patched if it spans two pages, is there any on
when TCG goto_tb can be generated?
Kind regards,
Sergey
Re: [Qemu-devel] tcg: reworking tb_invalidated_flag, Richard Henderson, 2016/03/30
Re: [Qemu-devel] tcg: reworking tb_invalidated_flag, Alex Bennée, 2016/03/31