Documentation/arch/arm64/cpu-feature-registers.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/arm64/cpu-feature-registers.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/arm64/cpu-feature-registers.rst
Extension
.rst
Size
18512 bytes
Lines
420
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

===========================
ARM64 CPU Feature Registers
===========================

Author: Suzuki K Poulose <suzuki.poulose@arm.com>


This file describes the ABI for exporting the AArch64 CPU ID/feature
registers to userspace. The availability of this ABI is advertised
via the HWCAP_CPUID in HWCAPs.

1. Motivation
-------------

The ARM architecture defines a set of feature registers, which describe
the capabilities of the CPU/system. Access to these system registers is
restricted from EL0 and there is no reliable way for an application to
extract this information to make better decisions at runtime. There is
limited information available to the application via HWCAPs, however
there are some issues with their usage.

 a) Any change to the HWCAPs requires an update to userspace (e.g libc)
    to detect the new changes, which can take a long time to appear in
    distributions. Exposing the registers allows applications to get the
    information without requiring updates to the toolchains.

 b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
    when ld is initialised at startup time).

 c) HWCAPs cannot represent non-boolean information effectively. The
    architecture defines a canonical format for representing features
    in the ID registers; this is well defined and is capable of
    representing all valid architecture variations.


2. Requirements
---------------

 a) Safety:

    Applications should be able to use the information provided by the
    infrastructure to run safely across the system. This has greater
    implications on a system with heterogeneous CPUs.
    The infrastructure exports a value that is safe across all the
    available CPU on the system.

    e.g, If at least one CPU doesn't implement CRC32 instructions, while
    others do, we should report that the CRC32 is not implemented.
    Otherwise an application could crash when scheduled on the CPU
    which doesn't support CRC32.

 b) Security:

    Applications should only be able to receive information that is
    relevant to the normal operation in userspace. Hence, some of the
    fields are masked out(i.e, made invisible) and their values are set to
    indicate the feature is 'not supported'. See Section 4 for the list
    of visible features. Also, the kernel may manipulate the fields
    based on what it supports. e.g, If FP is not supported by the
    kernel, the values could indicate that the FP is not available
    (even when the CPU provides it).

 c) Implementation Defined Features

    The infrastructure doesn't expose any register which is
    IMPLEMENTATION DEFINED as per ARMv8-A Architecture.

 d) CPU Identification:

    MIDR_EL1 is exposed to help identify the processor. On a

Annotation

Implementation Notes