linux-stable.git/arch/x86/kernel/tsc_sync.c, branch linux-rolling-stable

x86/msr: Add explicit includes of

2025-05-02T08:23:47+00:00

For historic reasons there are some TSC-related functions in the
 header, even though there's an  header.

To facilitate the relocation of rdtsc{,_ordered}() from 
to  and to eventually eliminate the inclusion of
 in , add an explicit  dependency
to the source files that reference definitions from .

[ mingo: Clarified the changelog. ]

Signed-off-by: Xin Li (Intel) 
Signed-off-by: Ingo Molnar 
Acked-by: Dave Hansen 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Ilpo Järvinen 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: Juergen Gross 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Kees Cook 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Josh Poimboeuf 
Cc: Uros Bizjak 
Link: https://lore.kernel.org/r/20250501054241.1245648-1-xin@zytor.com

x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'

2025-04-10T09:58:33+00:00

Suggested-by: "H. Peter Anvin" 
Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Cc: Juergen Gross 
Cc: Dave Hansen 
Cc: Xin Li 
Cc: Linus Torvalds

x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'

2025-04-10T09:58:27+00:00

Suggested-by: "H. Peter Anvin" 
Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Cc: Juergen Gross 
Cc: Dave Hansen 
Cc: Xin Li 
Cc: Linus Torvalds

x86/tsc: Trust initial offset in architectural TSC-adjust MSRs

2024-04-29T21:27:16+00:00

When the BIOS configures the architectural TSC-adjust MSRs on secondary
sockets to correct a constant inter-chassis offset, after Linux brings the
cores online, the TSC sync check later resets the core-local MSR to 0,
triggering HPET fallback and leading to performance loss.

Fix this by unconditionally using the initial adjust values read from the
MSRs. Trusting the initial offsets in this architectural mechanism is a
better approach than special-casing workarounds for specific platforms.

Signed-off-by: Daniel J Blueman 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Steffen Persvold 
Reviewed-by: James Cleverdon 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Prarit Bhargava 
Link: https://lore.kernel.org/r/20240419085146.175665-1-daniel@quora.org

x86/tsc: Defer marking TSC unstable to a worker

2023-10-27T18:36:57+00:00

Tetsuo reported the following lockdep splat when the TSC synchronization
fails during CPU hotplug:

   tsc: Marking TSC unstable due to check_tsc_sync_source failed
  
   WARNING: inconsistent lock state
   inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
   ffffffff8cfa1c78 (watchdog_lock){?.-.}-{2:2}, at: clocksource_watchdog+0x23/0x5a0
   {IN-HARDIRQ-W} state was registered at:
     _raw_spin_lock_irqsave+0x3f/0x60
     clocksource_mark_unstable+0x1b/0x90
     mark_tsc_unstable+0x41/0x50
     check_tsc_sync_source+0x14f/0x180
     sysvec_call_function_single+0x69/0x90

   Possible unsafe locking scenario:
     lock(watchdog_lock);
     
       lock(watchdog_lock);

   stack backtrace:
    _raw_spin_lock+0x30/0x40
    clocksource_watchdog+0x23/0x5a0
    run_timer_softirq+0x2a/0x50
    sysvec_apic_timer_interrupt+0x6e/0x90

The reason is the recent conversion of the TSC synchronization function
during CPU hotplug on the control CPU to a SMP function call. In case
that the synchronization with the upcoming CPU fails, the TSC has to be
marked unstable via clocksource_mark_unstable().

clocksource_mark_unstable() acquires 'watchdog_lock', but that lock is
taken with interrupts enabled in the watchdog timer callback to minimize
interrupt disabled time. That's obviously a possible deadlock scenario,

Before that change the synchronization function was invoked in thread
context so this could not happen.

As it is not crucical whether the unstable marking happens slightly
delayed, defer the call to a worker thread which avoids the lock context
problem.

Fixes: 9d349d47f0e3 ("x86/smpboot: Make TSC synchronization function call based")
Reported-by: Tetsuo Handa 
Signed-off-by: Thomas Gleixner 
Tested-by: Tetsuo Handa 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87zg064ceg.ffs@tglx

x86/smpboot: Make TSC synchronization function call based

2023-05-15T11:44:53+00:00

Spin-waiting on the control CPU until the AP reaches the TSC
synchronization is just a waste especially in the case that there is no
synchronization required.

As the synchronization has to run with interrupts disabled the control CPU
part can just be done from a SMP function call. The upcoming AP issues that
call async only in the case that synchronization is required.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Tested-by: Michael Kelley 
Tested-by: Oleksandr Natalenko 
Tested-by: Helge Deller  # parisc
Tested-by: Guilherme G. Piccoli  # Steam Deck
Link: https://lore.kernel.org/r/20230512205256.148255496@linutronix.de

x86/tsc: Add a timer to make sure TSC_adjust is always checked

2021-12-01T23:40:35+00:00

The TSC_ADJUST register is checked every time a CPU enters idle state, but
Thomas Gleixner mentioned there is still a caveat that a system won't enter
idle [1], either because it's too busy or configured purposely to not enter
idle.

Setup a periodic timer (every 10 minutes) to make sure the check is
happening on a regular base.

[1] https://lore.kernel.org/lkml/875z286xtk.fsf@nanos.tec.linutronix.de/

Fixes: 6e3cd95234dc ("x86/hpet: Use another crystalball to evaluate HPET usability")
Requested-by: Thomas Gleixner 
Signed-off-by: Feng Tang 
Signed-off-by: Thomas Gleixner 
Cc: "Paul E. McKenney" 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211117023751.24190-1-feng.tang@intel.com

x86: Fix various typos in comments, take #2

2021-03-21T22:50:28+00:00

Fix another ~42 single-word typos in arch/x86/ code comments,
missed a few in the first pass, in particular in .S files.

Signed-off-by: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Paolo Bonzini 
Cc: Bjorn Helgaas 
Cc: linux-kernel@vger.kernel.org

x86: Fix a handful of typos

2020-02-16T19:58:06+00:00

Fix a couple of typos in code comments.

 [ bp: While at it: s/IRQ's/IRQs/. ]

Signed-off-by: Martin Molnar 
Signed-off-by: Borislav Petkov 
Reviewed-by: Randy Dunlap 
Link: https://lkml.kernel.org/r/0819a044-c360-44a4-f0b6-3f5bafe2d35c@gmail.com

x86/tsc: Remove redundant assignment

2020-01-22T12:52:42+00:00

Previously, the assignment to the local variable 'now' took place
before the for loop. The loop is unconditional so it will be entered
at least once. The variable 'now' is reassigned in the loop and is not
used before reassigning. Therefore, the assignment before the loop is
unnecessary and can be removed.

No code changed:

  # arch/x86/kernel/tsc_sync.o:

   text    data     bss     dec     hex filename
   3569     198      44    3811     ee3 tsc_sync.o.before
   3569     198      44    3811     ee3 tsc_sync.o.after

md5:
   36216de29b208edbcd34fed9fe7f7b69  tsc_sync.o.before.asm
   36216de29b208edbcd34fed9fe7f7b69  tsc_sync.o.after.asm

 [ bp: Massage commit message. ]

Signed-off-by: Mateusz Nosek 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20200118171143.25178-1-mateusznosek0@gmail.com