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 -- To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
