From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0UT3-0007D3-OP for qemu-devel@nongnu.org; Wed, 11 May 2016 09:46:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0USz-0004oO-FB for qemu-devel@nongnu.org; Wed, 11 May 2016 09:46:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0USz-0004oC-8x for qemu-devel@nongnu.org; Wed, 11 May 2016 09:46:21 -0400 References: <1459870344-16773-1-git-send-email-alex.bennee@linaro.org> <1459870344-16773-5-git-send-email-alex.bennee@linaro.org> <572CE0CD.3040004@gmail.com> <57332C6A.1080006@redhat.com> <57333578.4080609@gmail.com> From: Paolo Bonzini Message-ID: <573337A4.2030101@redhat.com> Date: Wed, 11 May 2016 15:46:12 +0200 MIME-Version: 1.0 In-Reply-To: <57333578.4080609@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v2 04/11] tcg: comment on which functions have to be called with tb_lock held List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov , =?UTF-8?Q?Alex_Benn=c3=a9e?= , mttcg@greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, cota@braap.org Cc: peter.maydell@linaro.org, claudio.fontana@huawei.com, Peter Crosthwaite , jan.kiszka@siemens.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, =?UTF-8?Q?Andreas_F=c3=a4rber?= , rth@twiddle.net 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_l= ock >>> 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 MTTC= G. >> I think there was such a patch somewhere, but: tb_lock basically >> protects tcg_ctx, while mmap_lock protects the user-mode emulation pag= e >> 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. >=20 > 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. :) Thanks, Paolo