Documentation/arch/x86/cpuinfo.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/x86/cpuinfo.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/x86/cpuinfo.rst
Extension
.rst
Size
9579 bytes
Lines
207
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

=================
x86 Feature Flags
=================

Introduction
============

The list of feature flags in /proc/cpuinfo is not complete and
represents an ill-fated attempt from long time ago to put feature flags
in an easy to find place for userspace.

However, the number of feature flags is growing with each CPU generation,
leading to unparseable and unwieldy /proc/cpuinfo.

What is more, those feature flags do not even need to be in that file
because userspace doesn't care about them - glibc et al already use
CPUID to find out what the target machine supports and what not.

And even if it doesn't show a particular feature flag - although the CPU
still does have support for the respective hardware functionality and
said CPU supports CPUID faulting - userspace can simply probe for the
feature and figure out if it is supported or not, regardless of whether
it is being advertised somewhere.

Furthermore, those flag strings become an ABI the moment they appear
there and maintaining them forever when nothing even uses them is a lot
of wasted effort.

So, the current use of /proc/cpuinfo is to show features which the
kernel has *enabled* and *supports*. As in: the CPUID feature flag is
there, there's an additional setup which the kernel has done while
booting and the functionality is ready to use. A perfect example for
that is "user_shstk" where additional code enablement is present in the
kernel to support shadow stack for user programs.

So, if users want to know if a feature is available on a given system,
they try to find the flag in /proc/cpuinfo. If a given flag is present,
it means that

* the kernel knows about the feature enough to have an X86_FEATURE bit

* the kernel supports it and is currently making it available either to
  userspace or some other part of the kernel

* if the flag represents a hardware feature the hardware supports it.

The absence of a flag in /proc/cpuinfo by itself means almost nothing to
an end user.

On the one hand, a feature like "vaes" might be fully available to user
applications on a kernel that has not defined X86_FEATURE_VAES and thus
there is no "vaes" in /proc/cpuinfo.

On the other hand, a new kernel running on non-VAES hardware would also
have no "vaes" in /proc/cpuinfo.  There's no way for an application or
user to tell the difference.

The end result is that the flags field in /proc/cpuinfo is marginally
useful for kernel debugging, but not really for anything else.
Applications should instead use things like the glibc facilities for
querying CPU support.  Users should rely on tools like
tools/arch/x86/kcpuid and cpuid(1).

Regarding implementation, flags appearing in /proc/cpuinfo have an
X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. These flags
represent hardware features as well as software features.

If the kernel cares about a feature or KVM want to expose the feature to

Annotation

Implementation Notes