From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8DwR-0005pG-4t for qemu-devel@nongnu.org; Wed, 01 Jun 2016 17:44:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8DwO-0007GN-R5 for qemu-devel@nongnu.org; Wed, 01 Jun 2016 17:44:41 -0400 Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]:35218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8DwG-0007Bs-64 for qemu-devel@nongnu.org; Wed, 01 Jun 2016 17:44:40 -0400 Received: by mail-it0-x22d.google.com with SMTP id z189so95236480itg.0 for ; Wed, 01 Jun 2016 14:44:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <327cf7e0-6f2a-177c-2537-383ea2f26fe4@twiddle.net> References: <20160531183928.29406-1-bobby.prani@gmail.com> <20160531183928.29406-3-bobby.prani@gmail.com> <6f2b3338-e5cd-3d4c-354b-0997a9fd6bd9@twiddle.net> <327cf7e0-6f2a-177c-2537-383ea2f26fe4@twiddle.net> From: Pranith Kumar Date: Wed, 1 Jun 2016 17:44:02 -0400 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [RFC v2 PATCH 02/13] tcg/i386: Add support for fence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: "open list:i386 target" , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Sergey Fedorov On Wed, Jun 1, 2016 at 5:17 PM, Richard Henderson wrote: > > Because x86 has a strong memory model. > > It does not require barriers to keep normal loads and stores in order. The > primary reason for the *fence instructions is to order the "non-temporal" > memory operations that are part of the SSE instruction set, which we're not > using at all. > > This is why you'll find > > /* > * Because of the strongly ordered storage model, wmb() and rmb() are nops > * here (a compiler barrier only). QEMU doesn't do accesses to > write-combining > * qemu memory or non-temporal load/stores from C code. > */ > #define smp_wmb() barrier() > #define smp_rmb() barrier() > > for x86 and s390. OK. For x86 target, that is true. I think I got the context confused. On x86 target, we can elide the read and write barriers. But we still need to generate 'mfence' to prevent store-after-load reordering. I will refine this in the next version. Thanks, -- Pranith