From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41359)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.bennee@linaro.org>) id 1bFQMI-00078U-Dr
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 14:25:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex.bennee@linaro.org>) id 1bFQME-000162-6n
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 14:25:09 -0400
Received: from mail-lb0-x236.google.com ([2a00:1450:4010:c04::236]:35076)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.bennee@linaro.org>) id 1bFQMD-00015w-VO
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 14:25:06 -0400
Received: by mail-lb0-x236.google.com with SMTP id o4so15733348lbp.2
	for <qemu-devel@nongnu.org>; Tue, 21 Jun 2016 11:25:05 -0700 (PDT)
From: Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
In-reply-to: <CAJhHMCA0_UgwVyx2DdhrAmEpXsOPs5TaqXcuJW26LdAxngeHZg@mail.gmail.com>
Date: Tue, 21 Jun 2016 19:25:08 +0100
Message-ID: <87twgmqu0r.fsf@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences
 for x86
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: Pranith Kumar <bobby.prani@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>, "open list:All patches CC here" <qemu-devel@nongnu.org>, Sergey Fedorov <serge.fdrv@gmail.com>, Eduardo Habkost <ehabkost@redhat.com>, Richard Henderson <rth@twiddle.net>


Pranith Kumar <bobby.prani@gmail.com> writes:

> On Tue, Jun 21, 2016 at 1:54 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 21 June 2016 at 18:28, Pranith Kumar <bobby.prani@gmail.com> wrote:
>>> Reg. the second point, I did consider this situation of running x86 on
>>> ARM where such barriers are necessary for correctness. But, I am
>>> really apprehensive of the cost it will impose. I am not sure if there
>>> are any alternative solutions to avoid generating barriers for each
>>> memory operation, but it would be great if we could reduce them.
>>
>> I vaguely recall an idea that you could avoid needing
>> explicit barriers by turning all the guest load/stores into
>> host load-acquire/store-release, but I have no idea whether
>> that's (a) actually true (b) any better than piles of
>> explicit barriers.
>
> Yes, this is true for ARMv8(not sure about ia64). The
> load-acquire/store-release operations are sequentially consistent to
> each other. But this does not work for ARMv7 and as you said... I
> think the cost here too is really prohibitive.

If the cost ends up being too prohibitive (as in -smp N runs slower and
slower) then we may just keep -accel tcg,thread=single the default for
that combination.

We need some hard numbers either way.

--
Alex Bennée