From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49059)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1ZCRMV-0006ec-2N
	for qemu-devel@nongnu.org; Tue, 07 Jul 2015 07:48:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1ZCRMS-00048S-0w
	for qemu-devel@nongnu.org; Tue, 07 Jul 2015 07:48:30 -0400
Received: from greensocs.com ([193.104.36.180]:33174)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1ZCRMR-00048M-Qw
	for qemu-devel@nongnu.org; Tue, 07 Jul 2015 07:48:27 -0400
Message-ID: <559BBC88.5030402@greensocs.com>
Date: Tue, 07 Jul 2015 13:48:24 +0200
From: Frederic Konrad <fred.konrad@greensocs.com>
MIME-Version: 1.0
References: <1435330053-18733-1-git-send-email-fred.konrad@greensocs.com>
	<1435330053-18733-3-git-send-email-fred.konrad@greensocs.com>
	<87r3ok9sur.fsf@linaro.org> <559BA87E.70601@redhat.com>
In-Reply-To: <559BA87E.70601@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC PATCH V6 02/18] replace spinlock by QemuMutex.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>
Cc: mttcg@greensocs.com, peter.maydell@linaro.org, a.spyridakis@virtualopensystems.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, alistair.francis@xilinx.com, agraf@suse.de, guillaume.delbergue@greensocs.com

On 07/07/2015 12:22, Paolo Bonzini wrote:
>
> On 07/07/2015 12:15, Alex Benn=C3=A9e wrote:
>> Why are the locking rules different for CONFIG_USER versus system
>> emulation? Looking at the final tree:
>>
>>>>                   tb =3D tb_find_fast(env);
>> this eventually ends up doing a tb_lock on the find_slow path which II=
RC
>> is when might end up doing the actual code generation.
>>
> Up to this point, system emulation is using the BQL for everything.  I
> guess things change later.
>
> Paolo
Actually we use tb_lock to protect all the tb related structure such as=20
TBContext
etc.. Is it better to use the global lock for this?

Fred