linux-yocto/Documentation/ABI/testing/sysfs-devices-system-cpu
Mark Gross 9ecf57e4aa x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation
commit 7e5b3c267d upstream

SRBDS is an MDS-like speculative side channel that can leak bits from the
random number generator (RNG) across cores and threads. New microcode
serializes the processor access during the execution of RDRAND and
RDSEED. This ensures that the shared buffer is overwritten before it is
released for reuse.

While it is present on all affected CPU models, the microcode mitigation
is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
cases where TSX is not supported or has been disabled with TSX_CTRL.

The mitigation is activated by default on affected processors and it
increases latency for RDRAND and RDSEED instructions. Among other
effects this will reduce throughput from /dev/urandom.

* Enable administrator to configure the mitigation off when desired using
  either mitigations=off or srbds=off.

* Export vulnerability status via sysfs

* Rename file-scoped macros to apply for non-whitelist table initializations.

 [ bp: Massage,
   - s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g,
   - do not read arch cap MSR a second time in tsx_fused_off() - just pass it in,
   - flip check in cpu_set_bug_bits() to save an indentation level,
   - reflow comments.
   jpoimboe: s/Mitigated/Mitigation/ in user-visible strings
   tglx: Dropped the fused off magic for now
 ]

Signed-off-by: Mark Gross <mgross@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Tested-by: Neelima Krishnan <neelima.krishnan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-11 09:23:01 +02:00

16 KiB

What: /sys/devices/system/cpu/ Date: pre-git history Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: A collection of both global and individual CPU attributes

	Individual CPU attributes are contained in subdirectories
	named by the kernel's logical CPU number, e.g.:

	/sys/devices/system/cpu/cpu#/

What: /sys/devices/system/cpu/kernel_max /sys/devices/system/cpu/offline /sys/devices/system/cpu/online /sys/devices/system/cpu/possible /sys/devices/system/cpu/present Date: December 2008 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: CPU topology files that describe kernel limits related to hotplug. Briefly:

	kernel_max: the maximum cpu index allowed by the kernel
	configuration.

	offline: cpus that are not online because they have been
	HOTPLUGGED off or exceed the limit of cpus allowed by the
	kernel configuration (kernel_max above).

	online: cpus that are online and being scheduled.

	possible: cpus that have been allocated resources and can be
	brought online if they are present.

	present: cpus that have been identified as being present in
	the system.

	See Documentation/cputopology.txt for more information.

What: /sys/devices/system/cpu/probe /sys/devices/system/cpu/release Date: November 2009 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Dynamic addition and removal of CPU's. This is not hotplug removal, this is meant complete removal/addition of the CPU from the system.

	probe: writes to this file will dynamically add a CPU to the
	system.  Information written to the file to add CPU's is
	architecture specific.

	release: writes to this file dynamically remove a CPU from
	the system.  Information writtento the file to remove CPU's
	is architecture specific.

What: /sys/devices/system/cpu/cpu#/node Date: October 2009 Contact: Linux memory management mailing list linux-mm@kvack.org Description: Discover NUMA node a CPU belongs to

	When CONFIG_NUMA is enabled, a symbolic link that points
	to the corresponding NUMA node directory.

	For example, the following symlink is created for cpu42
	in NUMA node 2:

	/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2

What: /sys/devices/system/cpu/cpu#/topology/core_id /sys/devices/system/cpu/cpu#/topology/core_siblings /sys/devices/system/cpu/cpu#/topology/core_siblings_list /sys/devices/system/cpu/cpu#/topology/physical_package_id /sys/devices/system/cpu/cpu#/topology/thread_siblings /sys/devices/system/cpu/cpu#/topology/thread_siblings_list Date: December 2008 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: CPU topology files that describe a logical CPU's relationship to other cores and threads in the same physical package.

	One cpu# directory is created per logical CPU in the system,
	e.g. /sys/devices/system/cpu/cpu42/.

	Briefly, the files above are:

	core_id: the CPU core ID of cpu#. Typically it is the
	hardware platform's identifier (rather than the kernel's).
	The actual value is architecture and platform dependent.

	core_siblings: internal kernel map of cpu#'s hardware threads
	within the same physical_package_id.

	core_siblings_list: human-readable list of the logical CPU
	numbers within the same physical_package_id as cpu#.

	physical_package_id: physical package id of cpu#. Typically
	corresponds to a physical socket number, but the actual value
	is architecture and platform dependent.

	thread_siblings: internel kernel map of cpu#'s hardware
	threads within the same core as cpu#

	thread_siblings_list: human-readable list of cpu#'s hardware
	threads within the same core as cpu#

	See Documentation/cputopology.txt for more information.

What: /sys/devices/system/cpu/cpuidle/current_driver /sys/devices/system/cpu/cpuidle/current_governer_ro Date: September 2007 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Discover cpuidle policy and mechanism

	Various CPUs today support multiple idle levels that are
	differentiated by varying exit latencies and power
	consumption during idle.

	Idle policy (governor) is differentiated from idle mechanism
	(driver)

	current_driver: displays current idle mechanism

	current_governor_ro: displays current idle policy

	See files in Documentation/cpuidle/ for more information.

What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history Contact: linux-pm@vger.kernel.org Description: Discover and change clock speed of CPUs

	Clock scaling allows you to change the clock speed of the
	CPUs on the fly. This is a nice method to save battery
	power, because the lower the clock speed, the less power
	the CPU consumes.

	There are many knobs to tweak in this directory.

	See files in Documentation/cpu-freq/ for more information.

	In particular, read Documentation/cpu-freq/user-guide.txt
	to learn how to control the knobs.

What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus Date: June 2013 Contact: linux-pm@vger.kernel.org Description: Discover CPUs in the same CPU frequency coordination domain

	freqdomain_cpus is the list of CPUs (online+offline) that share
	the same clock/freq domain (possibly at the hardware level).
	That information may be hidden from the cpufreq core and the
	value of related_cpus may be different from freqdomain_cpus. This
	attribute is useful for user space DVFS controllers to get better
	power/performance results for platforms using acpi-cpufreq.

	This file is only present if the acpi-cpufreq driver is in use.

What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1} Date: August 2008 KernelVersion: 2.6.27 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Disable L3 cache indices

	These files exist in every CPU's cache/index3 directory. Each
	cache_disable_{0,1} file corresponds to one disable slot which
	can be used to disable a cache index. Reading from these files
	on a processor with this functionality will return the currently
	disabled index for that node. There is one L3 structure per
	node, or per internal node on MCM machines. Writing a valid
	index to one of these files will cause the specificed cache
	index to be disabled.

	All AMD processors with L3 caches provide this functionality.
	For details, see BKDGs at
	http://developer.amd.com/documentation/guides/Pages/default.aspx

What: /sys/devices/system/cpu/cpufreq/boost Date: August 2012 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Processor frequency boosting control

	This switch controls the boost setting for the whole system.
	Boosting allows the CPU and the firmware to run at a frequency
	beyound it's nominal limit.
	More details can be found in Documentation/cpu-freq/boost.txt

What: /sys/devices/system/cpu/cpu#/crash_notes /sys/devices/system/cpu/cpu#/crash_notes_size Date: April 2013 Contact: kexec@lists.infradead.org Description: address and size of the percpu note.

	crash_notes: the physical address of the memory that holds the
	note of cpu#.

	crash_notes_size: size of the note of cpu#.

What: /sys/devices/system/cpu/intel_pstate/max_perf_pct /sys/devices/system/cpu/intel_pstate/min_perf_pct /sys/devices/system/cpu/intel_pstate/no_turbo Date: February 2013 Contact: linux-pm@vger.kernel.org Description: Parameters for the Intel P-state driver

	Logic for selecting the current P-state in Intel
	Sandybridge+ processors. The three knobs control
	limits for the P-state that will be requested by the
	driver.

	max_perf_pct: limits the maximum P state that will be requested by
	the driver stated as a percentage of the available performance.

	min_perf_pct: limits the minimum P state that will be requested by
	the driver stated as a percentage of the available performance.

	no_turbo: limits the driver to selecting P states below the turbo
	frequency range.

	More details can be found in Documentation/cpu-freq/intel-pstate.txt

What: /sys/devices/system/cpu/cpu*/cache/index*/<set_of_attributes_mentioned_below> Date: July 2014(documented, existed before August 2008) Contact: Sudeep Holla sudeep.holla@arm.com Linux kernel mailing list linux-kernel@vger.kernel.org Description: Parameters for the CPU cache attributes

	allocation_policy:
		- WriteAllocate: allocate a memory location to a cache line
				 on a cache miss because of a write
		- ReadAllocate: allocate a memory location to a cache line
				on a cache miss because of a read
		- ReadWriteAllocate: both writeallocate and readallocate

	attributes: LEGACY used only on IA64 and is same as write_policy

	coherency_line_size: the minimum amount of data in bytes that gets
			     transferred from memory to cache

	level: the cache hierarchy in the multi-level cache configuration

	number_of_sets: total number of sets in the cache, a set is a
			collection of cache lines with the same cache index

	physical_line_partition: number of physical cache line per cache tag

	shared_cpu_list: the list of logical cpus sharing the cache

	shared_cpu_map: logical cpu mask containing the list of cpus sharing
			the cache

	size: the total cache size in kB

	type:
		- Instruction: cache that only holds instructions
		- Data: cache that only caches data
		- Unified: cache that holds both data and instructions

	ways_of_associativity: degree of freedom in placing a particular block
				of memory in the cache

	write_policy:
		- WriteThrough: data is written to both the cache line
				and to the block in the lower-level memory
		- WriteBack: data is written only to the cache line and
			     the modified cache line is written to main
			     memory only when it is replaced

What: /sys/devices/system/cpu/cpu*/cache/index*/id Date: September 2016 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Cache id

	The id provides a unique number for a specific instance of
	a cache of a particular type. E.g. there may be a level
	3 unified cache on each socket in a server and we may
	assign them ids 0, 1, 2, ...

	Note that id value can be non-contiguous. E.g. level 1
	caches typically exist per core, but there may not be a
	power of two cores on a socket, so these caches may be
	numbered 0, 1, 2, 3, 4, 5, 8, 9, 10, ...

What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/unthrottle /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/powercap /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/supply_fault /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overcurrent /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset Date: March 2016 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Linux for PowerPC mailing list linuxppc-dev@ozlabs.org Description: POWERNV CPUFreq driver's frequency throttle stats directory and attributes

	'cpuX/cpufreq/throttle_stats' directory contains the CPU frequency
	throttle stat attributes for the chip. The throttle stats of a cpu
	is common across all the cpus belonging to a chip. Below are the
	throttle attributes exported in the 'throttle_stats' directory:

	- turbo_stat : This file gives the total number of times the max
	frequency is throttled to lower frequency in turbo (at and above
	nominal frequency) range of frequencies.

	- sub_turbo_stat : This file gives the total number of times the
	max frequency is throttled to lower frequency in sub-turbo(below
	nominal frequency) range of frequencies.

	- unthrottle : This file gives the total number of times the max
	frequency is unthrottled after being throttled.

	- powercap : This file gives the total number of times the max
	frequency is throttled due to 'Power Capping'.

	- overtemp : This file gives the total number of times the max
	frequency is throttled due to 'CPU Over Temperature'.

	- supply_fault : This file gives the total number of times the
	max frequency is throttled due to 'Power Supply Failure'.

	- overcurrent : This file gives the total number of times the
	max frequency is throttled due to 'Overcurrent'.

	- occ_reset : This file gives the total number of times the max
	frequency is throttled due to 'OCC Reset'.

	The sysfs attributes representing different throttle reasons like
	powercap, overtemp, supply_fault, overcurrent and occ_reset map to
	the reasons provided by OCC firmware for throttling the frequency.

What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/turbo_stat /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/sub_turbo_stat /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/unthrottle /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/powercap /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overtemp /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/supply_fault /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overcurrent /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset Date: March 2016 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Linux for PowerPC mailing list linuxppc-dev@ozlabs.org Description: POWERNV CPUFreq driver's frequency throttle stats directory and attributes

	'policyX/throttle_stats' directory and all the attributes are same as
	the /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory and
	attributes which give the frequency throttle information of the chip.

What: /sys/devices/system/cpu/cpuX/regs/ /sys/devices/system/cpu/cpuX/regs/identification/ /sys/devices/system/cpu/cpuX/regs/identification/midr_el1 /sys/devices/system/cpu/cpuX/regs/identification/revidr_el1 Date: June 2016 Contact: Linux ARM Kernel Mailing list linux-arm-kernel@lists.infradead.org Description: AArch64 CPU registers 'identification' directory exposes the CPU ID registers for identifying model and revision of the CPU.

What: /sys/devices/system/cpu/cpu#/cpu_capacity Date: December 2016 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: information about CPUs heterogeneity.

	cpu_capacity: capacity of cpu#.

What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/meltdown /sys/devices/system/cpu/vulnerabilities/spectre_v1 /sys/devices/system/cpu/vulnerabilities/spectre_v2 /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Information about CPU vulnerabilities

	The files are named after the code names of CPU
	vulnerabilities. The output of those files reflects the
	state of the CPUs in the system. Possible output values:

	"Not affected"	  CPU is not affected by the vulnerability
	"Vulnerable"	  CPU is affected and no mitigation in effect
	"Mitigation: $M"  CPU is affected and mitigation $M is in effect

	See also: Documentation/admin-guide/hw-vuln/index.rst

What: /sys/devices/system/cpu/smt /sys/devices/system/cpu/smt/active /sys/devices/system/cpu/smt/control Date: June 2018 Contact: Linux kernel mailing list linux-kernel@vger.kernel.org Description: Control Symetric Multi Threading (SMT)

	active:  Tells whether SMT is active (enabled and siblings online)

	control: Read/write interface to control SMT. Possible
		 values:

		 "on"		SMT is enabled
		 "off"		SMT is disabled
		 "forceoff"	SMT is force disabled. Cannot be changed.
		 "notsupported" SMT is not supported by the CPU

		 If control status is "forceoff" or "notsupported" writes
		 are rejected.