]> git.baikalelectronics.ru Git - kernel.git/commit
x86: Remove X86_FEATURE_MFENCE_RDTSC
authorJosh Poimboeuf <jpoimboe@redhat.com>
Thu, 4 Jul 2019 15:46:37 +0000 (10:46 -0500)
committerThomas Gleixner <tglx@linutronix.de>
Mon, 22 Jul 2019 10:00:51 +0000 (12:00 +0200)
commit91755834d6fbc12b130b6afc88c493375cb076c4
tree062d6c937566a4c9f3151384a41b4b38a30dc2f8
parentec2a4bc1a8741781c48a5940d9b00a1a6f3235e0
x86: Remove X86_FEATURE_MFENCE_RDTSC

AMD and Intel both have serializing lfence (X86_FEATURE_LFENCE_RDTSC).
They've both had it for a long time, and AMD has had it enabled in Linux
since Spectre v1 was announced.

Back then, there was a proposal to remove the serializing mfence feature
bit (X86_FEATURE_MFENCE_RDTSC), since both AMD and Intel have
serializing lfence.  At the time, it was (ahem) speculated that some
hypervisors might not yet support its removal, so it remained for the
time being.

Now a year-and-a-half later, it should be safe to remove.

I asked Andrew Cooper about whether it's still needed:

  So if you're virtualised, you've got no choice in the matter.  lfence
  is either dispatch-serialising or not on AMD, and you won't be able to
  change it.

  Furthermore, you can't accurately tell what state the bit is in, because
  the MSR might not be virtualised at all, or may not reflect the true
  state in hardware.  Worse still, attempting to set the bit may not be
  successful even if there isn't a fault for doing so.

  Xen sets the DE_CFG bit unconditionally, as does Linux by the looks of
  things (see MSR_F10H_DECFG_LFENCE_SERIALIZE_BIT).  ISTR other hypervisor
  vendors saying the same, but I don't have any information to hand.

  If you are running under a hypervisor which has been updated, then
  lfence will almost certainly be dispatch-serialising in practice, and
  you'll almost certainly see the bit already set in DE_CFG.  If you're
  running under a hypervisor which hasn't been patched since Spectre,
  you've already lost in many more ways.

  I'd argue that X86_FEATURE_MFENCE_RDTSC is not worth keeping.

So remove it.  This will reduce some code rot, and also make it easier
to hook barrier_nospec() up to a cmdline disable for performance
raisins, without having to need an alternative_3() macro.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/d990aa51e40063acb9888e8c1b688e41355a9588.1562255067.git.jpoimboe@redhat.com
arch/x86/include/asm/barrier.h
arch/x86/include/asm/cpufeatures.h
arch/x86/include/asm/msr.h
arch/x86/kernel/cpu/amd.c
arch/x86/kernel/cpu/hygon.c
tools/arch/x86/include/asm/cpufeatures.h