From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50356)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZUN8N-0000rI-Ie
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:56:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZUN8I-0002XK-KK
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:56:03 -0400
Received: from mx6-phx2.redhat.com ([209.132.183.39]:35015)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZUN8I-0002X7-CG
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:55:58 -0400
Date: Tue, 25 Aug 2015 18:55:53 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <1465982421.18985670.1440543353356.JavaMail.zimbra@redhat.com>
In-Reply-To: <20150825030240.GD8880@flamenco>
References: <1440375847-17603-1-git-send-email-cota@braap.org>
	<1440375847-17603-21-git-send-email-cota@braap.org>
	<55DA7443.3030901@redhat.com> <20150825030240.GD8880@flamenco>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC 20/38] tcg/i386: implement fences
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: "Emilio G. Cota" <cota@braap.org>
Cc: mttcg@greensocs.com, mark burton <mark.burton@greensocs.com>, a rigo <a.rigo@virtualopensystems.com>, qemu-devel@nongnu.org, guillaume delbergue <guillaume.delbergue@greensocs.com>, alex bennee <alex.bennee@linaro.org>, Frederic Konrad <fred.konrad@greensocs.com>


> lfence and sfence here serve two purposes:
> 
> 1) Template for other architectures

Ok, this makes sense.

> 2) x86 code does sometimes have lfence/sfence (e.g. movntq+sfence),
>    so I guessed they should remain in the translated code.
>    If on x86 we always ignore the Write-Combining from the
>    guest, maybe we could claim the l/sfence pair here is really unnecessary.

Yeah, I think it's fair enough to ignore WC and nontemporal stores.

>    I didn't intend to translate say *all* PPC/ARM load barriers
>    into lfences when generating x86, which is I think your point.

Yeah, it's just that the only gen_op_smp_rmb() you had in the RFC
also did not need an lfence.  But it seems like we're on the same
page.

Paolo