Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Aug 03, 2016 at 09:50:25AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 03 Aug 2016, Michael S. Tsirkin wrote:
> > > And I'm still discussing this with the hardware people.  It seems we
> > > can do this for *most* things, but not all; the question is where
> > > exactly we need to do something different.
> 
> Let's hope the "hardware guys" get back to you soon :(
> 
> 
>      HSD162/BDM116  MOVNTDQA From WC Memory May Pass Earlier Locked
>                     Instructions
> 
>      Problem: An execution of (V)MOVNTDQA (streaming load instruction)
>      that loads from WC (write combining) memory may appear to pass an
>      earlier locked instruction that accesses a different cache line.
> 
>      Implication: Software that expects a lock to fence subsequent
>      (V)MOVNTDQA instructions may not operate properly.
> 
>      Workaround: None identified.  Software that relies on a locked
>      instruction to fence subsequent executions of (V)MOVNTDQA should
>      insert an MFENCE instruction between the locked instruction and
>      subsequent (V)MOVNTDQA instruction.
> 
> 
> 
>      SKL079   MOVNTDQA From WC Memory May Pass Earlier MFENCE Instructions
> 
>      Problem: An execution of MOVNTDQA or VMOVNTDQA that loads from WC
>      (write combining) memory may appear to pass an earlier execution of
>      the MFENCE instruction.
> 
>      Implication: When this erratum occurs, an execution of MOVNTDQA or
>      VMOVNTDQA may appear to execute before memory operations that
>      precede the earlier MFENCE instruction.  Software that uses MFENCE
>      to order subsequent executions of the MOVNTDQA instructions may not
>      operate properly.
> 
>      Workaround: It is possible for the BIOS to contain a workaround for
>      this erratum.  For the steppings affected, see the Summary Table of
>      Changes.
> 
> 
> These are just examples.  Intel might have other errata related to
> *FENCE or LOCK, and AMD might have its share of model-specific LOCK or
> *FENCE oddities as well (I didn't check).
> 
> Note that Skylake is broken in exactly the opposite way that Haswell and
> Broadwell are.  Fortunately, Skylake could be fixed through a microcode
> update, but still...
> 
> The point is that we indeed need to be careful if we want to switch away
> from *FENCE.

Are any of these used in kernel though?

> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh