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

x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possible

2025-11-12T23:29:38+00:00

Extend KVM's export macro framework to provide EXPORT_SYMBOL_FOR_KVM(),
and use the helper macro to export symbols for KVM throughout x86 if and
only if KVM will build one or more modules, and only for those modules.

To avoid unnecessary exports when CONFIG_KVM=m but kvm.ko will not be
built (because no vendor modules are selected), let arch code #define
EXPORT_SYMBOL_FOR_KVM to suppress/override the exports.

Note, the set of symbols to restrict to KVM was generated by manual search
and audit; any "misses" are due to human error, not some grand plan.

Signed-off-by: Sean Christopherson 
Signed-off-by: Dave Hansen 
Acked-by: Kai Huang 
Tested-by: Kai Huang 
Link: https://patch.msgid.link/20251112173944.1380633-5-seanjc%40google.com

x86/cpuid: Set as the main CPUID header

2025-05-15T16:23:55+00:00

The main CPUID header  was originally a storefront for the
headers:

    
    

Now that the latter CPUID(0x2) header has been merged into the former,
there is no practical difference between  and
.

Migrate all users to the  header, in preparation of
the removal of .

Don't remove  just yet, in case some new code in -next
started using it.

Suggested-by: Ingo Molnar 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: Andrew Cooper 
Cc: H. Peter Anvin 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250508150240.172915-3-darwi@linutronix.de

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 '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: Always save/restore TSC sched_clock() on suspend/resume

2025-02-21T14:27:38+00:00

TSC could be reset in deep ACPI sleep states, even with invariant TSC.

That's the reason we have sched_clock() save/restore functions, to deal
with this situation. But what happens is that such functions are guarded
with a check for the stability of sched_clock - if not considered stable,
the save/restore routines aren't executed.

On top of that, we have a clear comment in native_sched_clock() saying
that *even* with TSC unstable, we continue using TSC for sched_clock due
to its speed.

In other words, if we have a situation of TSC getting detected as unstable,
it marks the sched_clock as unstable as well, so subsequent S3 sleep cycles
could bring bogus sched_clock values due to the lack of the save/restore
mechanism, causing warnings like this:

  [22.954918] ------------[ cut here ]------------
  [22.954923] Delta way too big! 18446743750843854390 ts=18446744072977390405 before=322133536015 after=322133536015 write stamp=18446744072977390405
  [22.954923] If you just came from a suspend/resume,
  [22.954923] please switch to the trace global clock:
  [22.954923]   echo global > /sys/kernel/tracing/trace_clock
  [22.954923] or add trace_clock=global to the kernel command line
  [22.954937] WARNING: CPU: 2 PID: 5728 at kernel/trace/ring_buffer.c:2890 rb_add_timestamp+0x193/0x1c0

Notice that the above was reproduced even with "trace_clock=global".

The fix for that is to _always_ save/restore the sched_clock on suspend
cycle _if TSC is used_ as sched_clock - only if we fallback to jiffies
the sched_clock_stable() check becomes relevant to save/restore the
sched_clock.

Debugged-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Guilherme G. Piccoli 
Signed-off-by: Ingo Molnar 
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250215210314.351480-1-gpiccoli@igalia.com

Merge tag 'x86_cpu_for_v6.14_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2025-01-21T17:30:59+00:00

Pull x86 cpuid updates from Borislav Petkov:

 - Remove the less generic CPU matching infra around struct x86_cpu_desc
   and use the generic struct x86_cpu_id thing

 - Remove magic naked numbers for CPUID functions and use proper defines
   of the prefix CPUID_LEAF_*. Consolidate some of the crazy use around
   the tree

 - Smaller cleanups and improvements

* tag 'x86_cpu_for_v6.14_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/cpu: Make all all CPUID leaf names consistent
  x86/fpu: Remove unnecessary CPUID level check
  x86/fpu: Move CPUID leaf definitions to common code
  x86/tsc: Remove CPUID "frequency" leaf magic numbers.
  x86/tsc: Move away from TSC leaf magic numbers
  x86/cpu: Move TSC CPUID leaf definition
  x86/cpu: Refresh DCA leaf reading code
  x86/cpu: Remove unnecessary MwAIT leaf checks
  x86/cpu: Use MWAIT leaf definition
  x86/cpu: Move MWAIT leaf definition to common header
  x86/cpu: Remove 'x86_cpu_desc' infrastructure
  x86/cpu: Move AMD erratum 1386 table over to 'x86_cpu_id'
  x86/cpu: Replace PEBS use of 'x86_cpu_desc' use with 'x86_cpu_id'
  x86/cpu: Expose only stepping min/max interface
  x86/cpu: Introduce new microcode matching helper
  x86/cpufeature: Document cpu_feature_enabled() as the default to use
  x86/paravirt: Remove the WBINVD callback
  x86/cpufeatures: Free up unused feature bits

x86/tsc: Init the TSC for Secure TSC guests

2025-01-08T20:26:19+00:00

Use the GUEST_TSC_FREQ MSR to discover the TSC frequency instead of
relying on kvm-clock based frequency calibration.  Override both CPU and
TSC frequency calibration callbacks with securetsc_get_tsc_khz(). Since
the difference between CPU base and TSC frequency does not apply in this
case, the same callback is being used.

  [ bp: Carve out from
    https://lore.kernel.org/r/20250106124633.1418972-11-nikunj@amd.com ]

Signed-off-by: Nikunj A Dadhania 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/20250106124633.1418972-11-nikunj@amd.com

x86/cpu: Make all all CPUID leaf names consistent

2024-12-18T14:17:46+00:00

The leaf names are not consistent.  Give them all a CPUID_LEAF_ prefix
for consistency and vertical alignment.

Signed-off-by: Dave Hansen 
Acked-by: Dave Jiang  # for ioatdma bits
Link: https://lore.kernel.org/all/20241213205040.7B0C3241%40davehans-spike.ostc.intel.com

x86/tsc: Remove CPUID "frequency" leaf magic numbers.

2024-12-18T14:17:40+00:00

All the code that reads the CPUID frequency information leaf hard-codes
a magic number.  Give it a symbolic name and use it.

Signed-off-by: Dave Hansen 
Reviewed-by: Zhao Liu 
Link: https://lore.kernel.org/all/20241213205036.4397658F%40davehans-spike.ostc.intel.com

x86/tsc: Move away from TSC leaf magic numbers

2024-12-18T14:17:38+00:00

The TSC code has a bunch of hard-coded references to leaf 0x15.  Change
them over to the symbolic name.  Also zap the 'ART_CPUID_LEAF' definition.
It was a duplicate of 'CPUID_TSC_LEAF'.

Signed-off-by: Dave Hansen 
Link: https://lore.kernel.org/all/20241213205034.B79D6224%40davehans-spike.ostc.intel.com