]> git.hungrycats.org Git - linux/commit
x86/speculation: Handle HT correctly on AMD
authorThomas Gleixner <tglx@linutronix.de>
Wed, 9 May 2018 19:53:09 +0000 (21:53 +0200)
committerBen Hutchings <ben@decadent.org.uk>
Wed, 3 Oct 2018 03:09:46 +0000 (04:09 +0100)
commitaf108cc9145299e70235a574e65b5b34ed13ef9c
treeb26d995b05b3e47646628f1ffe5792224cc97c55
parent340cfe03f30081d124632fe7408065b1bb54adeb
x86/speculation: Handle HT correctly on AMD

commit 1f50ddb4f4189243c05926b842dc1a0332195f31 upstream.

The AMD64_LS_CFG MSR is a per core MSR on Family 17H CPUs. That means when
hyperthreading is enabled the SSBD bit toggle needs to take both cores into
account. Otherwise the following situation can happen:

CPU0 CPU1

disable SSB
disable SSB
enable  SSB <- Enables it for the Core, i.e. for CPU0 as well

So after the SSB enable on CPU1 the task on CPU0 runs with SSB enabled
again.

On Intel the SSBD control is per core as well, but the synchronization
logic is implemented behind the per thread SPEC_CTRL MSR. It works like
this:

  CORE_SPEC_CTRL = THREAD0_SPEC_CTRL | THREAD1_SPEC_CTRL

i.e. if one of the threads enables a mitigation then this affects both and
the mitigation is only disabled in the core when both threads disabled it.

Add the necessary synchronization logic for AMD family 17H. Unfortunately
that requires a spinlock to serialize the access to the MSR, but the locks
are only shared between siblings.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16:
 - s/topology_sibling_cpumask/topology_thread_cpumask/
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
arch/x86/include/asm/spec-ctrl.h
arch/x86/kernel/process.c
arch/x86/kernel/smpboot.c