qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2 04/11] tcg: comment on which functions have to


From: Sergey Fedorov
Subject: Re: [Qemu-devel] [RFC v2 04/11] tcg: comment on which functions have to be called with tb_lock held
Date: Thu, 12 May 2016 22:32:40 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 11/05/16 16:46, Paolo Bonzini wrote:
> On 11/05/2016 15:36, Sergey Fedorov wrote:
>> On 11/05/16 15:58, Paolo Bonzini wrote:
>>> On 06/05/2016 20:22, Sergey Fedorov wrote:
>>>> However, there's no sensible description of what is protected by tb_lock
>>>> and mmap_lock. I think we need to have a clear documented description of
>>>> the TCG locking scheme in order to be sure we do right things in MTTCG.
>>> I think there was such a patch somewhere, but: tb_lock basically
>>> protects tcg_ctx, while mmap_lock protects the user-mode emulation page
>>> table (the equivalent for system emulation is the memory map which is
>>> protected by the BQL).  Furthermore, mmap_lock must be taken outside
>>> tb_lock.
>> What's a user-mode emulation page table? 'l1_map'?
> Yes.  It's used beyond TCG in user-mode emulation.
>
>> It is used by system
>> emulation to keep track of TBs per page and 'code_bitmap'. Shouldn't it
>> be protected with 'mmap_lock' in system emulation?
> tb_lock is used instead because it's taken everywhere system emulation
> uses l1_map; so tb_lock is protecting l1_map too in system emulation.
>
> As mentioned above, user-mode emulation uses l1_map in linux-user/mmap.c
> via page_{get,set}_flags, which I guess is why the lock is separate.
> None of us was involved in the original multi-threaded linux-user work,
> we're reverse engineering it just like you. :)

While I'm investigating 'tb_lock' and 'mmap_lock' usage I am wondering
why don't put 'l1_map' into 'tcg_ctx'?

Kind regards,
Sergey



reply via email to

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