linux.git/arch/x86/kernel/cpu/proc.c, branch v6.6

x86: Expose thread features in /proc/$PID/status

2023-08-02T22:01:51+00:00

Applications and loaders can have logic to decide whether to enable
shadow stack. They usually don't report whether shadow stack has been
enabled or not, so there is no way to verify whether an application
actually is protected by shadow stack.

Add two lines in /proc/$PID/status to report enabled and locked features.

Since, this involves referring to arch specific defines in asm/prctl.h,
implement an arch breakout to emit the feature lines.

[Switched to CET, added to commit log]

Co-developed-by: Kirill A. Shutemov 
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Rick Edgecombe 
Signed-off-by: Dave Hansen 
Reviewed-by: Borislav Petkov (AMD) 
Reviewed-by: Kees Cook 
Acked-by: Mike Rapoport (IBM) 
Tested-by: Pengfei Xu 
Tested-by: John Allen 
Tested-by: Kees Cook 
Link: https://lore.kernel.org/all/20230613001108.3040476-37-rick.p.edgecombe%40intel.com

x86/aperfmperf: Integrate the fallback code from show_cpuinfo()

2022-04-27T18:22:20+00:00

Due to the avoidance of IPIs to idle CPUs arch_freq_get_on_cpu() can return
0 when the last sample was too long ago.

show_cpuinfo() has a fallback to cpufreq_quick_get() and if that fails to
return cpu_khz, but the readout code for the per CPU scaling frequency in
sysfs does not.

Move that fallback into arch_freq_get_on_cpu() so the behaviour is the same
when reading /proc/cpuinfo and /sys/..../cur_scaling_freq.

Suggested-by: "Rafael J. Wysocki" 
Signed-off-by: Thomas Gleixner 
Tested-by: Doug Smythies 
Link: https://lore.kernel.org/r/87pml5180p.ffs@tglx

x86/aperfmperf: Replace arch_freq_get_on_cpu()

2022-04-27T18:22:19+00:00

Reading the current CPU frequency from /sys/..../scaling_cur_freq involves
in the worst case two IPIs due to the ad hoc sampling.

The frequency invariance infrastructure provides the APERF/MPERF samples
already. Utilize them and consolidate this with the /proc/cpuinfo readout.

The sample is considered valid for 20ms. So for idle or isolated NOHZ full
CPUs the function returns 0, which is matching the previous behaviour.

The resulting text size vs. the original APERF/MPERF plus the separate
frequency invariance code:

  text:		2411	->   723
  init.text:	   0	->   767

Signed-off-by: Thomas Gleixner 
Tested-by: Eric Dumazet 
Reviewed-by: Rafael J. Wysocki 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Paul E. McKenney 
Link: https://lore.kernel.org/r/20220415161206.934040006@linutronix.de

x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_*

2020-01-13T17:36:02+00:00

Add support for generating VMX feature names in capflags.c and use the
resulting x86_vmx_flags to print the VMX flags in /proc/cpuinfo.  Don't
print VMX flags if no bits are set in word 0, which holds Pin Controls.
Pin Control's INTR and NMI exiting are fundamental pillars of VMX, if
they are not supported then the CPU is broken, it does not actually
support VMX, or the kernel wasn't built with support for the target CPU.

Print the features in a dedicated "vmx flags" line to avoid polluting
the common "flags" and to avoid having to prefix all flags with "vmx_",
which results in horrendously long names.

Keep synthetic VMX flags in cpufeatures to preserve /proc/cpuinfo's ABI
for those flags.  This means that "flags" and "vmx flags" will have
duplicate entries for tpr_shadow (virtual_tpr), vnmi, ept, flexpriority,
vpid and ept_ad, but caps the pollution of "flags" at those six VMX
features.  The vendor-specific code that populates the synthetic flags
will be consolidated in a future patch to further minimize the lasting
damage.

Signed-off-by: Sean Christopherson 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20191221044513.21680-12-sean.j.christopherson@intel.com

x86: Convert some slow-path static_cpu_has() callers to boot_cpu_has()

2019-04-08T10:13:34+00:00

Using static_cpu_has() is pointless on those paths, convert them to the
boot_cpu_has() variant.

No functional changes.

Reported-by: Nadav Amit 
Signed-off-by: Borislav Petkov 
Reviewed-by: Rik van Riel 
Reviewed-by: Juergen Gross  # for paravirt
Cc: Aubrey Li 
Cc: Dave Hansen 
Cc: Dominik Brodowski 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jann Horn 
Cc: Joerg Roedel 
Cc: "Kirill A. Shutemov" 
Cc: Konrad Rzeszutek Wilk 
Cc: Thomas Lendacky 
Cc: linux-edac@vger.kernel.org
Cc: Masami Hiramatsu 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Sebastian Andrzej Siewior 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: virtualization@lists.linux-foundation.org
Cc: x86@kernel.org
Link: https://lkml.kernel.org/r/20190330112022.28888-3-bp@alien8.de

x86/cpu: Change type of x86_cache_size variable to unsigned int

2018-02-15T00:15:53+00:00

Currently, x86_cache_size is of type int, which makes no sense as we
will never have a valid cache size equal or less than 0. So instead of
initializing this variable to -1, it can perfectly be initialized to 0
and use it as an unsigned variable instead.

Suggested-by: Thomas Gleixner 
Signed-off-by: Gustavo A. R. Silva 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Addresses-Coverity-ID: 1464429
Link: http://lkml.kernel.org/r/20180213192208.GA26414@embeddedor.com
Signed-off-by: Ingo Molnar

x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping

2018-02-15T00:15:52+00:00

x86_mask is a confusing name which is hard to associate with the
processor's stepping.

Additionally, correct an indent issue in lib/cpu.c.

Signed-off-by: Jia Zhang 
[ Updated it to more recent kernels. ]
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: bp@alien8.de
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com
Signed-off-by: Ingo Molnar

x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

2017-11-15T18:46:50+00:00

After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration.  That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.

To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".

However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs.  Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.

Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.

Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki 
Acked-by: Thomas Gleixner 
Tested-by: Thomas Gleixner 
Acked-by: Ingo Molnar

Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"

2017-11-10T19:19:11+00:00

This reverts commit 941f5f0f6ef5338814145cf2b813cf1f98873e2f.

Sadly, it turns out that we really can't just do the cross-CPU IPI to
all CPU's to get their proper frequencies, because it's much too
expensive on systems with lots of cores.

So we'll have to revert this for now, and revisit it using a smarter
model (probably doing one system-wide IPI at open time, and doing all
the frequency calculations in parallel).

Reported-by: WANG Chao 
Reported-by: Ingo Molnar 
Cc: Rafael J Wysocki 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo

2017-11-03T15:50:13+00:00

Commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for
/proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous
behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes
made after the commit it has reverted.

To address this, make the code in question use arch_freq_get_on_cpu()
which also is used by cpufreq for reporting the current frequency of
CPUs and since that function doesn't really depend on cpufreq in any
way, drop the CONFIG_CPU_FREQ dependency for the object file
containing it.

Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and
return cached values right away if it is called very often over a
short time (to prevent user space from triggering IPI storms through
it).

Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Cc: stable@kernel.org   # 4.13 - together with 890da9cf0983
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Linus Torvalds