linux.git/arch/x86/kernel/tsc_sync.c, branch v4.12

x86/tsc: Make the TSC ADJUST sanitizing work for tsc_reliable

2017-02-10T08:47:17+00:00

When the TSC is marked reliable then the synchronization check is skipped,
but that also skips the TSC ADJUST sanitizing code. So on a machine with a
wreckaged BIOS the TSC deviation between CPUs might go unnoticed.

Let the TSC adjust sanitizing code run unconditionally and just skip the
expensive synchronization checks when TSC is marked reliable.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Olof Johansson 
Link: http://lkml.kernel.org/r/20170209151231.491189912@linutronix.de
Signed-off-by: Thomas Gleixner

x86/tsc: Limit the adjust value further

2016-12-18T15:37:04+00:00

Adjust value 0x80000000 and other values larger than that render the TSC
deadline timer disfunctional.

We have not yet any information about this from Intel, but experimentation
clearly proves that this is a 32/64 bit and sign extension issue.

If adjust values larger than that are actually required, which might be the
case for physical CPU hotplug, then we need to disable the deadline timer
on the affected package/CPUs and use the local APIC timer instead.

That requires some surgery in the APIC setup code, so we just limit the
ADJUST register value into the known to work range for now and revisit this
when Intel comes forth with proper information.

Signed-off-by: Thomas Gleixner 
Cc: Roland Scheidegger 
Cc: Bruce Schlobohm 
Cc: Kevin Stanton 
Cc: Peter Zijlstra 
Cc: Borislav Petkov

x86/tsc: Annotate printouts as firmware bug

2016-12-18T15:35:15+00:00

Make it more obvious that the BIOS is screwed up.

Signed-off-by: Thomas Gleixner 
Cc: Roland Scheidegger 
Cc: Bruce Schlobohm 
Cc: Kevin Stanton 
Cc: Peter Zijlstra 
Cc: Borislav Petkov

x86/tsc: Force TSC_ADJUST register to value >= zero

2016-12-15T10:44:29+00:00

Roland reported that his DELL T5810 sports a value add BIOS which
completely wreckages the TSC. The squirmware [(TM) Ingo Molnar] boots with
random negative TSC_ADJUST values, different on all CPUs. That renders the
TSC useless because the sycnchronization check fails.

Roland tested the new TSC_ADJUST mechanism. While it manages to readjust
the TSCs he needs to disable the TSC deadline timer, otherwise the machine
just stops booting.

Deeper investigation unearthed that the TSC deadline timer is sensitive to
the TSC_ADJUST value. Writing TSC_ADJUST to a negative value results in an
interrupt storm caused by the TSC deadline timer.

This does not make any sense and it's hard to imagine what kind of hardware
wreckage is behind that misfeature, but it's reliably reproducible on other
systems which have TSC_ADJUST and TSC deadline timer.

While it would be understandable that a big enough negative value which
moves the resulting TSC readout into the negative space could have the
described effect, this happens even with a adjust value of -1, which keeps
the TSC readout definitely in the positive space. The compare register for
the TSC deadline timer is set to a positive value larger than the TSC, but
despite not having reached the deadline the interrupt is raised
immediately. If this happens on the boot CPU, then the machine dies
silently because this setup happens before the NMI watchdog is armed.

Further experiments showed that any other adjustment of TSC_ADJUST works as
expected as long as it stays in the positive range. The direction of the
adjustment has no influence either. See the lkml link for further analysis.

Yet another proof for the theory that timers are designed by janitors and
the underlying (obviously undocumented) mechanisms which allow BIOSes to
wreckage them are considered a feature. Well done Intel - NOT!

To address this wreckage add the following sanity measures:

- If the TSC_ADJUST value on the boot cpu is not 0, set it to 0

- If the TSC_ADJUST value on any cpu is negative, set it to 0

- Prevent the cross package synchronization mechanism from setting negative
  TSC_ADJUST values.

Reported-and-tested-by: Roland Scheidegger 
Signed-off-by: Thomas Gleixner 
Cc: Bruce Schlobohm 
Cc: Kevin Stanton 
Cc: Peter Zijlstra 
Cc: Allen Hung 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/20161213131211.397588033@linutronix.de
Signed-off-by: Thomas Gleixner

x86/tsc: Validate TSC_ADJUST after resume

2016-12-15T10:44:29+00:00

Some 'feature' BIOSes fiddle with the TSC_ADJUST register during
suspend/resume which renders the TSC unusable.

Add sanity checks into the resume path and restore the
original value if it was adjusted.

Reported-and-tested-by: Roland Scheidegger 
Signed-off-by: Thomas Gleixner 
Cc: Bruce Schlobohm 
Cc: Kevin Stanton 
Cc: Peter Zijlstra 
Cc: Allen Hung 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/20161213131211.317654500@linutronix.de
Signed-off-by: Thomas Gleixner

x86/tsc: Validate cpumask pointer before accessing it

2016-12-01T13:40:52+00:00

0-day testing encountered a NULL pointer dereference in a cpumask access
from tsc_store_and_check_tsc_adjust().

This happens when the function is called on the boot CPU and the topology
masks are not yet available due to CPUMASK_OFFSTACK=y.

Add a NULL pointer check for the mask pointer. If NULL it's safe to assume
that the CPU is the boot CPU and the first one in the package.

Fixes: 8b223bc7abe0 ("x86/tsc: Store and check TSC ADJUST MSR")
Reported-by: kernel test robot 
Signed-off-by: Thomas Gleixner

x86/tsc: Fix broken CONFIG_X86_TSC=n build

2016-11-30T08:44:52+00:00

Add the missing return statement to the inline stub
tsc_store_and_check_tsc_adjust() and add the other stubs to make a
SMP=y,TSC=n build happy.

While at it, remove the unused variable from the UP variant of
tsc_store_and_check_tsc_adjust().

Fixes: commit ba75fb646931 ("x86/tsc: Sync test only for the first cpu in a package")
Reported-by: kbuild test robot 
Signed-off-by: Thomas Gleixner

x86/tsc: Try to adjust TSC if sync test fails

2016-11-29T18:23:18+00:00

If the first CPU of a package comes online, it is necessary to test whether
the TSC is in sync with a CPU on some other package. When a deviation is
observed (time going backwards between the two CPUs) the TSC is marked
unstable, which is a problem on large machines as they have to fall back to
the HPET clocksource, which is insanely slow.

It has been attempted to compensate the TSC by adding the offset to the TSC
and writing it back some time ago, but this never was merged because it did
not turn out to be stable, especially not on older systems.

Modern systems have become more stable in that regard and the TSC_ADJUST
MSR allows us to compensate for the time deviation in a sane way. If it's
available allow up to three synchronization runs and if a time warp is
detected the starting CPU can compensate the time warp via the TSC_ADJUST
MSR and retry. If the third run still shows a deviation or when random time
warps are detected the test terminally fails.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Yinghai Lu 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/20161119134018.048237517@linutronix.de
Signed-off-by: Thomas Gleixner

x86/tsc: Prepare warp test for TSC adjustment

2016-11-29T18:23:18+00:00

To allow TSC compensation cross nodes its necessary to know in which
direction the TSC warp was observed. Return the maximum observed value on
the calling CPU so the caller can determine the direction later.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Yinghai Lu 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/20161119134017.970859287@linutronix.de
Signed-off-by: Thomas Gleixner

x86/tsc: Move sync cleanup to a safe place

2016-11-29T18:23:18+00:00

Cleaning up the stop marker on the control CPU is wrong when we want to add
retry support. Move the cleanup to the starting CPU.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Yinghai Lu 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/20161119134017.892095627@linutronix.de
Signed-off-by: Thomas Gleixner