Re: [Qemu-devel] [PATCH 3/3] tcg: Avoid bouncing tb_lock between tb_gen_code() and tb_add_jump()

[Paolo Bonzini]

On 11/07/2016 15:06, Sergey Fedorov wrote:
> On 08/07/16 23:52, Paolo Bonzini wrote:
>>
>> On 08/07/2016 22:24, Sergey Fedorov wrote:
>>> I remember, I've just found that we discussed it in this thread:
>>>
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/401723/focus=406852
>>>
>>> I was thinking of just doing 'tb_jmp_cache' lookup out of the lock, not
>>> tb_find_physical(). Now thanks to QHT, we could do tb_find_physical()
>>> out of the lock, too. This changes things.
>> But in my patch ("tcg: move tb_find_fast outside the tb_lock critical
>> section", which originally was written by Fred---most of my contribution
>> was getting the invalidation right, not the lock-free lookup)
>> tb_find_physical was also done out of the lock.  It was then retried
>> inside the lock, if it failed.
>>
>> This is why I needed to fail all concurrent lookups as the first step in
>> the invalidation.
>>
>> Emilio's QHT resulted in a rewrite of tb_find_physical, but the basic
>> concepts are the same.
> 
> That could work, I think, if we re-check under tb_lock whether the TB is
> still valid before adding a direct jump to it.

Right, this can still happen:

        tb_find_fast                    tb_phys_invalidate
                                         tb_lock
         jmp_cache miss
         -> tb_find_slow
          -> tb_find_physical
           QHT hit
         tb_lock
                                         invalidate tb->pc
                                         remove from lists
                                         tb_unlock
         tb_add_jump
         tb_unlock

I seem to recall that Emilio added a seqlock for this purpose, but
adding a tb_check_invalidated(TranslationBlock *tb) inline function will
also do.

Paolo