From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38647)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1bA1A2-0002lW-C0
	for qemu-devel@nongnu.org; Mon, 06 Jun 2016 16:30:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1bA19x-0003pR-4T
	for qemu-devel@nongnu.org; Mon, 06 Jun 2016 16:30:09 -0400
Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]:33079)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1bA19v-0003oK-GN
	for qemu-devel@nongnu.org; Mon, 06 Jun 2016 16:30:05 -0400
Received: by mail-lf0-x244.google.com with SMTP id j198so215836lfe.0
	for <qemu-devel@nongnu.org>; Mon, 06 Jun 2016 13:30:03 -0700 (PDT)
References: <20160531183928.29406-1-bobby.prani@gmail.com>
	<20160531183928.29406-2-bobby.prani@gmail.com>
	<57505F1A.3020808@gmail.com>
	<68c32d50-adc2-25b2-b136-2a486f6b3de7@twiddle.net>
	<5750995D.6030005@gmail.com>
	<8e9b8569-89a5-845a-a856-7f2fa4435659@twiddle.net>
	<CAJhHMCDEHkpcs0nk_CaBWphLkvsRtNDqDGkAiuSGSopVJqwPPw@mail.gmail.com>
	<57559A66.6040408@gmail.com>
	<CAJhHMCCPcTdAWcthP2HUFdwSHjgZoffKWg48vUP802wxVDXYTA@mail.gmail.com>
	<57559B93.7090003@gmail.com>
	<CAJhHMCBqyPC5T17T+wsCeRmZxPXCBtrV16pOQs144yM7g7ffYg@mail.gmail.com>
	<5755A164.9040709@gmail.com>
	<CAJhHMCD=KrnVrhMdHwgrZZmgG8FPuvr72uRrcCNzA9-A89v9yQ@mail.gmail.com>
	<f1ce9d83-720b-f0d2-b11f-da58f9bc8fa4@twiddle.net>
	<CAJhHMCBOszH12BpE4AJGwY3ZH4DevS2nFiCQR-R-UadMSOnb2Q@mail.gmail.com>
From: Sergey Fedorov <serge.fdrv@gmail.com>
Message-ID: <5755DD49.8030004@gmail.com>
Date: Mon, 6 Jun 2016 23:30:01 +0300
MIME-Version: 1.0
In-Reply-To: <CAJhHMCBOszH12BpE4AJGwY3ZH4DevS2nFiCQR-R-UadMSOnb2Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for
 memory barrier
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>, Richard Henderson <rth@twiddle.net>
Cc: "open list:All patches CC here" <qemu-devel@nongnu.org>, =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>

On 06/06/16 22:28, Pranith Kumar wrote:
> On Mon, Jun 6, 2016 at 3:23 PM, Richard Henderson <rth@twiddle.net> wrote:
>> On 06/06/2016 10:11 AM, Pranith Kumar wrote:
>>> If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the
>>> other four barriers. I am not sure if we can just construct SYNC like
>>> this or if we need to define it explicitly though.
>>
>> AFAICS, sparc membar #sync is stronger.
> I tried looking it up but it's not clear. How is it stronger? And do
> we need those strong guarantees in our front-end/back-end?

That is not clear for me either :( AFAIU, PPC's lwsync does allow stores
to be reordered after loads but hwsync - not. I suspect Sparc's membar
#Sync is used to ensure that some system operations are complete before
proceeding with execution. I'm not sure we need to introduce this into
TCG. It needs to be clear what is it and how to use it.

Kind regards,
Sergey