From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36427)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZCS5K-0000Ej-CM
	for qemu-devel@nongnu.org; Tue, 07 Jul 2015 08:34:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZCS5H-0004x7-Kg
	for qemu-devel@nongnu.org; Tue, 07 Jul 2015 08:34:50 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54190)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZCS5H-0004vC-GD
	for qemu-devel@nongnu.org; Tue, 07 Jul 2015 08:34:47 -0400
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>
	<559BBC88.5030402@greensocs.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <559BC75F.9000601@redhat.com>
Date: Tue, 7 Jul 2015 14:34:39 +0200
MIME-Version: 1.0
In-Reply-To: <559BBC88.5030402@greensocs.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: Frederic Konrad <fred.konrad@greensocs.com>, =?UTF-8?Q?Alex_Benn=c3=a9e?= <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 13:48, Frederic Konrad wrote:
>>> this eventually ends up doing a tb_lock on the find_slow path which IIRC
>>> 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.
>
> Actually we use tb_lock to protect all the tb related structure such as
> TBContext etc.. Is it better to use the global lock for this?

No, on the contrary.  But using the BQL is the status as of patch 2, so
it's okay to keep the #ifdefs.  Thanks for confirming that it changes
later in the patch.

Paolo