On 01/04/16 14:11, Alex Bennée wrote:
> Sergey Fedorov writes:
>
>> On 31/03/16 16:37, Alex Bennée wrote:
>>> Sergey Fedorov 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
buff
Sergey Fedorov writes:
> On 31/03/16 16:37, Alex Bennée wrote:
>> Sergey Fedorov 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 wou
On 31/03/2016 21:03, Sergey Fedorov wrote:
> Looks like we have to ensure all vCPUs are out of translated code when
> doing TB patching either doing tb_add_jump() or tb_phys_invalidate().
> Did I missed something?
Almost all TCG targets have naturally aligned instructions, so that's
not a proble
On 31/03/16 17:06, Sergey Fedorov wrote:
> It should be safe to invalidate a TB while some other CPU is executing
> its translated code.
Probably it's not safe to invalidate a TB while some other thread is
executing the translated code. Direct jumps to the TB being invalidated
should be reset. In
On 03/31/2016 05:42 AM, Sergey Fedorov wrote:
> On 31/03/16 13:48, Alex Bennée wrote:
>> I know we are system focused at the moment but does linux-user ever
>> flush groups of TBs, say when mappings change? Or does this trigger a
>> whole tb_flush?
>
> Yes, e.g. target_mmap() calls tb_invalidate_p
On 31/03/2016 16:35, Sergey Fedorov wrote:
>> > My plan was to use some kind of double buffering, where only half of
>> > code_gen_buffer is in use. At the end of tb_flush you call cpu_exit()
>> > on all CPUs, so that CPUs stop executing chained TBs from the old half
>> > before they can see one
On 31/03/16 16:40, Paolo Bonzini wrote:
>
> On 31/03/2016 15:14, Sergey Fedorov wrote:
>> On 30/03/16 21:13, Paolo Bonzini wrote:
>>> On 30/03/2016 19:08, Sergey Fedorov wrote:
The second approach is to make 'tb_invalidated_flag' per-CPU. This
would be conceptually similar to what we have
On 31/03/16 16:37, Alex Bennée wrote:
> Sergey Fedorov 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 translatio
On 31/03/2016 15:14, Sergey Fedorov wrote:
> On 30/03/16 21:13, Paolo Bonzini wrote:
>>
>> On 30/03/2016 19:08, Sergey Fedorov wrote:
>>> The second approach is to make 'tb_invalidated_flag' per-CPU. This
>>> would be conceptually similar to what we have, but would give us thread
>>> safety. With
Sergey Fedorov writes:
> On 30/03/16 21:13, Paolo Bonzini wrote:
>>
>> On 30/03/2016 19:08, Sergey Fedorov wrote:
>>> The second approach is to make 'tb_invalidated_flag' per-CPU. This
>>> would be conceptually similar to what we have, but would give us thread
>>> safety. With this approach, we
On 30/03/16 21:13, Paolo Bonzini wrote:
>
> On 30/03/2016 19:08, Sergey Fedorov wrote:
>> The second approach is to make 'tb_invalidated_flag' per-CPU. This
>> would be conceptually similar to what we have, but would give us thread
>> safety. With this approach, we need to be careful to correctly c
On 31/03/16 13:48, Alex Bennée wrote:
> I know we are system focused at the moment but does linux-user ever
> flush groups of TBs, say when mappings change? Or does this trigger a
> whole tb_flush?
Yes, e.g. target_mmap() calls tb_invalidate_phys_range().
Kind regards,
Sergey
Sergey Fedorov writes:
> Hi,
>
> This is a follow-up of the discussion [1]. The main focus is to move
> towards thread-safe TB invalidation and translation buffer flush.
> In addition, we can get more clean, readable and reliable code.
>
> First, I'd like to summarize how 'tb_invalidated_flag' i
On 30/03/16 22:08, Richard Henderson wrote:
> On 03/30/2016 10:08 AM, Sergey Fedorov wrote:
>> As of catching tb_flush() in cpu_exec() there have been three approaches
>> proposed.
>>
>> The first approach is to get rid of 'tb_invalidated_flag' and use
>> 'tb_flush_count'. Capture 'tb_flush_count'
On 03/30/2016 10:08 AM, Sergey Fedorov wrote:
> As of catching tb_flush() in cpu_exec() there have been three approaches
> proposed.
>
> The first approach is to get rid of 'tb_invalidated_flag' and use
> 'tb_flush_count'. Capture 'tb_flush_count' inside 'tb_lock' critical
> section of cpu_exec()
On 30/03/2016 19:08, Sergey Fedorov wrote:
> cpu_exec() case is a bit more subtle. Regarding tb_phys_invalidate(), it
> shouldn't be harmful if an invalidated TB get patched because it is not
> going to be executed anymore. It may only be a concern of efficiency.
> Though it doesn't seem to happe
Hi,
This is a follow-up of the discussion [1]. The main focus is to move
towards thread-safe TB invalidation and translation buffer flush.
In addition, we can get more clean, readable and reliable code.
First, I'd like to summarize how 'tb_invalidated_flag' is used.
Basically, 'tb_invalidated_fla
17 matches
Mail list logo
