<!DOCTYPE html>
<html lang="en" data-content_root="../../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>3. x86 Feature Flags — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../../_static/alabaster.css?v=3918102e" />
<script src="../../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../../_static/doctools.js?v=9bcbadda"></script>
<script src="../../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../../genindex.html" />
<link rel="search" title="Search" href="../../search.html" />
<link rel="next" title="4. x86 Topology" href="topology.html" />
<link rel="prev" title="2. DeviceTree Booting" href="booting-dt.html" />
<link rel="stylesheet" href="../../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../../index.html">
<img class="logo" src="../../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../process/index.html">All development-process docs</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../subsystem-apis.html">Subsystems</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul class="current">
<li class="toctree-l1 current"><a class="reference internal" href="../index.html">CPU architectures</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../arc/index.html">ARC architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../arm/index.html">ARM Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../arm64/index.html">ARM64 Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../loongarch/index.html">LoongArch Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../m68k/index.html">m68k Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../mips/index.html">MIPS-specific Documentation</a></li>
<li class="toctree-l2"><a class="reference internal" href="../nios2/index.html">Nios II Specific Documentation</a></li>
<li class="toctree-l2"><a class="reference internal" href="../openrisc/index.html">OpenRISC Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../parisc/index.html">PA-RISC Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../powerpc/index.html">powerpc</a></li>
<li class="toctree-l2"><a class="reference internal" href="../riscv/index.html">RISC-V architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../s390/index.html">s390 Architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="../sh/index.html">SuperH Interfaces Guide</a></li>
<li class="toctree-l2"><a class="reference internal" href="../sparc/index.html">Sparc Architecture</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="index.html">x86-specific Documentation</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="boot.html">1. The Linux/x86 Boot Protocol</a></li>
<li class="toctree-l3"><a class="reference internal" href="booting-dt.html">2. DeviceTree Booting</a></li>
<li class="toctree-l3 current"><a class="current reference internal" href="#">3. x86 Feature Flags</a></li>
<li class="toctree-l3"><a class="reference internal" href="topology.html">4. x86 Topology</a></li>
<li class="toctree-l3"><a class="reference internal" href="exception-tables.html">5. Kernel level exception handling</a></li>
<li class="toctree-l3"><a class="reference internal" href="kernel-stacks.html">6. Kernel Stacks</a></li>
<li class="toctree-l3"><a class="reference internal" href="entry_64.html">7. Kernel Entries</a></li>
<li class="toctree-l3"><a class="reference internal" href="earlyprintk.html">8. Early Printk</a></li>
<li class="toctree-l3"><a class="reference internal" href="orc-unwinder.html">9. ORC unwinder</a></li>
<li class="toctree-l3"><a class="reference internal" href="zero-page.html">10. Zero Page</a></li>
<li class="toctree-l3"><a class="reference internal" href="tlb.html">11. The TLB</a></li>
<li class="toctree-l3"><a class="reference internal" href="mtrr.html">12. MTRR (Memory Type Range Register) control</a></li>
<li class="toctree-l3"><a class="reference internal" href="pat.html">13. PAT (Page Attribute Table)</a></li>
<li class="toctree-l3"><a class="reference internal" href="intel-hfi.html">14. Hardware-Feedback Interface for scheduling on Intel Hardware</a></li>
<li class="toctree-l3"><a class="reference internal" href="shstk.html">15. Control-flow Enforcement Technology (CET) Shadow Stack</a></li>
<li class="toctree-l3"><a class="reference internal" href="iommu.html">16. x86 IOMMU Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="intel_txt.html">17. Intel(R) TXT Overview</a></li>
<li class="toctree-l3"><a class="reference internal" href="amd-debugging.html">18. Debugging AMD Zen systems</a></li>
<li class="toctree-l3"><a class="reference internal" href="amd-memory-encryption.html">19. AMD Memory Encryption</a></li>
<li class="toctree-l3"><a class="reference internal" href="amd_hsmp.html">20. AMD HSMP interface</a></li>
<li class="toctree-l3"><a class="reference internal" href="amd-hfi.html">21. Hardware Feedback Interface For Hetero Core Scheduling On AMD Platform</a></li>
<li class="toctree-l3"><a class="reference internal" href="tdx.html">22. Intel Trust Domain Extensions (TDX)</a></li>
<li class="toctree-l3"><a class="reference internal" href="pti.html">23. Page Table Isolation (PTI)</a></li>
<li class="toctree-l3"><a class="reference internal" href="mds.html">24. Microarchitectural Data Sampling (MDS) mitigation</a></li>
<li class="toctree-l3"><a class="reference internal" href="microcode.html">25. The Linux Microcode Loader</a></li>
<li class="toctree-l3"><a class="reference internal" href="tsx_async_abort.html">26. TSX Async Abort (TAA) mitigation</a></li>
<li class="toctree-l3"><a class="reference internal" href="buslock.html">27. Bus lock detection and handling</a></li>
<li class="toctree-l3"><a class="reference internal" href="usb-legacy-support.html">28. USB Legacy support</a></li>
<li class="toctree-l3"><a class="reference internal" href="i386/index.html">29. i386 Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="x86_64/index.html">30. x86_64 Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="ifs.html">31. In-Field Scan</a></li>
<li class="toctree-l3"><a class="reference internal" href="sva.html">32. Shared Virtual Addressing (SVA) with ENQCMD</a></li>
<li class="toctree-l3"><a class="reference internal" href="sgx.html">33. Software Guard eXtensions (SGX)</a></li>
<li class="toctree-l3"><a class="reference internal" href="features.html">34. Feature status on x86 architecture</a></li>
<li class="toctree-l3"><a class="reference internal" href="elf_auxvec.html">35. x86-specific ELF Auxiliary Vectors</a></li>
<li class="toctree-l3"><a class="reference internal" href="xstate.html">36. Using XSTATE features in user space applications</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../xtensa/index.html">Xtensa Architecture</a></li>
</ul>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../../_sources/arch/x86/cpuinfo.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="x86-feature-flags">
<h1><span class="section-number">3. </span>x86 Feature Flags<a class="headerlink" href="#x86-feature-flags" title="Link to this heading">¶</a></h1>
<section id="introduction">
<h2><span class="section-number">3.1. </span>Introduction<a class="headerlink" href="#introduction" title="Link to this heading">¶</a></h2>
<p>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.</p>
<p>However, the number of feature flags is growing with each CPU generation,
leading to unparseable and unwieldy /proc/cpuinfo.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>So, the current use of /proc/cpuinfo is to show features which the
kernel has <em>enabled</em> and <em>supports</em>. 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.</p>
<p>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</p>
<ul class="simple">
<li><p>the kernel knows about the feature enough to have an X86_FEATURE bit</p></li>
<li><p>the kernel supports it and is currently making it available either to
userspace or some other part of the kernel</p></li>
<li><p>if the flag represents a hardware feature the hardware supports it.</p></li>
</ul>
<p>The absence of a flag in /proc/cpuinfo by itself means almost nothing to
an end user.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>If the kernel cares about a feature or KVM want to expose the feature to
a KVM guest, it should only then expose it to the guest when the guest
needs to parse /proc/cpuinfo. Which, as mentioned above, is highly
unlikely. KVM can synthesize the CPUID bit and the KVM guest can simply
query CPUID and figure out what the hypervisor supports and what not. As
already stated, /proc/cpuinfo is not a dumping ground for useless
feature flags.</p>
</section>
<section id="how-are-feature-flags-created">
<h2><span class="section-number">3.2. </span>How are feature flags created?<a class="headerlink" href="#how-are-feature-flags-created" title="Link to this heading">¶</a></h2>
<section id="feature-flags-can-be-derived-from-the-contents-of-cpuid-leaves">
<h3><span class="section-number">3.2.1. </span>Feature flags can be derived from the contents of CPUID leaves<a class="headerlink" href="#feature-flags-can-be-derived-from-the-contents-of-cpuid-leaves" title="Link to this heading">¶</a></h3>
<p>These feature definitions are organized mirroring the layout of CPUID
leaves and grouped in words with offsets as mapped in <code class="xref c c-enum broken_xref docutils literal notranslate"><span class="pre">enum</span> <span class="pre">cpuid_leafs</span></code>
in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details).
If a feature is defined with a X86_FEATURE_<name> definition in
cpufeatures.h, and if it is detected at run time, the flags will be
displayed accordingly in /proc/cpuinfo. For example, the flag “avx2”
comes from X86_FEATURE_AVX2 in cpufeatures.h.</p>
</section>
<section id="flags-can-be-from-scattered-cpuid-based-features">
<h3><span class="section-number">3.2.2. </span>Flags can be from scattered CPUID-based features<a class="headerlink" href="#flags-can-be-from-scattered-cpuid-based-features" title="Link to this heading">¶</a></h3>
<p>Hardware features enumerated in sparsely populated CPUID leaves get
software-defined values. Still, CPUID needs to be queried to determine
if a given feature is present. This is done in <code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">init_scattered_cpuid_features()</span></code>.
For instance, X86_FEATURE_CQM_LLC is defined as 11*32 + 0 and its presence is
checked at runtime in the respective CPUID leaf [EAX=f, ECX=0] bit EDX[1].</p>
<p>The intent of scattering CPUID leaves is to not bloat <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span>
<span class="pre">cpuinfo_x86</span></code>.x86_capability[] unnecessarily. For instance, the CPUID leaf
[EAX=7, ECX=0] has 30 features and is dense, but the CPUID leaf [EAX=7, EAX=1]
has only one feature and would waste 31 bits of space in the x86_capability[]
array. Since there is a <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">cpuinfo_x86</span></code> for each possible CPU, the wasted
memory is not trivial.</p>
</section>
<section id="flags-can-be-created-synthetically-under-certain-conditions-for-hardware-features">
<h3><span class="section-number">3.2.3. </span>Flags can be created synthetically under certain conditions for hardware features<a class="headerlink" href="#flags-can-be-created-synthetically-under-certain-conditions-for-hardware-features" title="Link to this heading">¶</a></h3>
<p>Examples of conditions include whether certain features are present in
MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed
conditions are met, the features are enabled by the set_cpu_cap or
setup_force_cpu_cap macros. For example, if bit 5 is set in MSR_IA32_CORE_CAPS,
the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and
“split_lock_detect” will be displayed. The flag “ring3mwait” will be
displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors.</p>
</section>
<section id="flags-can-represent-purely-software-features">
<h3><span class="section-number">3.2.4. </span>Flags can represent purely software features<a class="headerlink" href="#flags-can-represent-purely-software-features" title="Link to this heading">¶</a></h3>
<p>These flags do not represent hardware features. Instead, they represent a
software feature implemented in the kernel. For example, Kernel Page Table
Isolation is purely software feature and its feature flag X86_FEATURE_PTI is
also defined in cpufeatures.h.</p>
</section>
</section>
<section id="naming-of-flags">
<h2><span class="section-number">3.3. </span>Naming of Flags<a class="headerlink" href="#naming-of-flags" title="Link to this heading">¶</a></h2>
<p>The script arch/x86/kernel/cpu/mkcapflags.sh processes the
#define X86_FEATURE_<name> from cpufeatures.h and generates the
x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the
resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming
of flags in the x86_cap/bug_flags[] are as follows:</p>
<section id="flags-do-not-appear-by-default-in-proc-cpuinfo">
<h3><span class="section-number">3.3.1. </span>Flags do not appear by default in /proc/cpuinfo<a class="headerlink" href="#flags-do-not-appear-by-default-in-proc-cpuinfo" title="Link to this heading">¶</a></h3>
<p>Feature flags are omitted by default from /proc/cpuinfo as it does not make
sense for the feature to be exposed to userspace in most cases. For example,
X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal
kernel feature used in the alternative runtime patching functionality. So the
flag does not appear in /proc/cpuinfo.</p>
</section>
<section id="specify-a-flag-name-if-absolutely-needed">
<h3><span class="section-number">3.3.2. </span>Specify a flag name if absolutely needed<a class="headerlink" href="#specify-a-flag-name-if-absolutely-needed" title="Link to this heading">¶</a></h3>
<p>If the comment on the line for the #define X86_FEATURE_* starts with a
double-quote character (“”), the string inside the double-quote characters
will be the name of the flags. For example, the flag “sse4_1” comes from
the comment “sse4_1” following the X86_FEATURE_XMM4_1 definition.</p>
<p>There are situations in which overriding the displayed name of the flag is
needed. For instance, /proc/cpuinfo is a userspace interface and must remain
constant. If, for some reason, the naming of X86_FEATURE_<name> changes, one
shall override the new naming with the name already used in /proc/cpuinfo.</p>
</section>
</section>
<section id="flags-are-missing-when-one-or-more-of-these-happen">
<h2><span class="section-number">3.4. </span>Flags are missing when one or more of these happen<a class="headerlink" href="#flags-are-missing-when-one-or-more-of-these-happen" title="Link to this heading">¶</a></h2>
<section id="the-hardware-does-not-enumerate-support-for-it">
<h3><span class="section-number">3.4.1. </span>The hardware does not enumerate support for it<a class="headerlink" href="#the-hardware-does-not-enumerate-support-for-it" title="Link to this heading">¶</a></h3>
<p>For example, when a new kernel is running on old hardware or the feature is
not enabled by boot firmware. Even if the hardware is new, there might be a
problem enabling the feature at run time, the flag will not be displayed.</p>
</section>
<section id="the-kernel-does-not-know-about-the-flag">
<h3><span class="section-number">3.4.2. </span>The kernel does not know about the flag<a class="headerlink" href="#the-kernel-does-not-know-about-the-flag" title="Link to this heading">¶</a></h3>
<p>For example, when an old kernel is running on new hardware.</p>
</section>
<section id="the-kernel-disabled-support-for-it-at-compile-time">
<h3><span class="section-number">3.4.3. </span>The kernel disabled support for it at compile-time<a class="headerlink" href="#the-kernel-disabled-support-for-it-at-compile-time" title="Link to this heading">¶</a></h3>
<p>For example, if Linear Address Masking (LAM) is not enabled when building (i.e.,
CONFIG_ADDRESS_MASKING is not selected) the flag “lam” will not show up.
Even though the feature will still be detected via CPUID, the kernel disables
it by clearing via setup_clear_cpu_cap(X86_FEATURE_LAM).</p>
</section>
<section id="the-feature-is-disabled-at-boot-time">
<h3><span class="section-number">3.4.4. </span>The feature is disabled at boot-time<a class="headerlink" href="#the-feature-is-disabled-at-boot-time" title="Link to this heading">¶</a></h3>
<p>A feature can be disabled either using a command-line parameter or because
it failed to be enabled. The command-line parameter clearcpuid= can be used
to disable features using the feature number as defined in
/arch/x86/include/asm/cpufeatures.h. For instance, User Mode Instruction
Protection can be disabled using clearcpuid=514. The number 514 is calculated
from #define X86_FEATURE_UMIP (16*32 + 2).</p>
<p>In addition, there exists a variety of custom command-line parameters that
disable specific features. The list of parameters includes, but is not limited
to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using
“no5lvl”.</p>
</section>
<section id="the-feature-was-known-to-be-non-functional">
<h3><span class="section-number">3.4.5. </span>The feature was known to be non-functional<a class="headerlink" href="#the-feature-was-known-to-be-non-functional" title="Link to this heading">¶</a></h3>
<p>The feature was known to be non-functional because a dependency was
missing at runtime. For example, AVX flags will not show up if XSAVE feature
is disabled since they depend on XSAVE feature. Another example would be broken
CPUs and them missing microcode patches. Due to that, the kernel decides not to
enable a feature.</p>
</section>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../../_sources/arch/x86/cpuinfo.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>