e9a83bd232
- A fair pile of RST conversions, many from Mauro. These create more than the usual number of simple but annoying merge conflicts with other trees, unfortunately. He has a lot more of these waiting on the wings that, I think, will go to you directly later on. - A new document on how to use merges and rebases in kernel repos, and one on Spectre vulnerabilities. - Various improvements to the build system, including automatic markup of function() references because some people, for reasons I will never understand, were of the opinion that :c:func:``function()`` is unattractive and not fun to type. - We now recommend using sphinx 1.7, but still support back to 1.4. - Lots of smaller improvements, warning fixes, typo fixes, etc. -----BEGIN PGP SIGNATURE----- iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAl0krAEPHGNvcmJldEBs d24ubmV0AAoJEBdDWhNsDH5Yg98H/AuLqO9LpOgUjF4LhyjxGPdzJkY9RExSJ7km gznyreLCZgFaJR+AY6YDsd4Jw6OJlPbu1YM/Qo3C3WrZVFVhgL/s2ebvBgCo50A8 raAFd8jTf4/mGCHnAqRotAPQ3mETJUk315B66lBJ6Oc+YdpRhwXWq8ZW2bJxInFF 3HDvoFgMf0KhLuMHUkkL0u3fxH1iA+KvDu8diPbJYFjOdOWENz/CV8wqdVkXRSEW DJxIq89h/7d+hIG3d1I7Nw+gibGsAdjSjKv4eRKauZs4Aoxd1Gpl62z0JNk6aT3m dtq4joLdwScydonXROD/Twn2jsu4xYTrPwVzChomElMowW/ZBBY= =D0eO -----END PGP SIGNATURE----- Merge tag 'docs-5.3' of git://git.lwn.net/linux Pull Documentation updates from Jonathan Corbet: "It's been a relatively busy cycle for docs: - A fair pile of RST conversions, many from Mauro. These create more than the usual number of simple but annoying merge conflicts with other trees, unfortunately. He has a lot more of these waiting on the wings that, I think, will go to you directly later on. - A new document on how to use merges and rebases in kernel repos, and one on Spectre vulnerabilities. - Various improvements to the build system, including automatic markup of function() references because some people, for reasons I will never understand, were of the opinion that :c:func:``function()`` is unattractive and not fun to type. - We now recommend using sphinx 1.7, but still support back to 1.4. - Lots of smaller improvements, warning fixes, typo fixes, etc" * tag 'docs-5.3' of git://git.lwn.net/linux: (129 commits) docs: automarkup.py: ignore exceptions when seeking for xrefs docs: Move binderfs to admin-guide Disable Sphinx SmartyPants in HTML output doc: RCU callback locks need only _bh, not necessarily _irq docs: format kernel-parameters -- as code Doc : doc-guide : Fix a typo platform: x86: get rid of a non-existent document Add the RCU docs to the core-api manual Documentation: RCU: Add TOC tree hooks Documentation: RCU: Rename txt files to rst Documentation: RCU: Convert RCU UP systems to reST Documentation: RCU: Convert RCU linked list to reST Documentation: RCU: Convert RCU basic concepts to reST docs: filesystems: Remove uneeded .rst extension on toctables scripts/sphinx-pre-install: fix out-of-tree build docs: zh_CN: submitting-drivers.rst: Remove a duplicated Documentation/ Documentation: PGP: update for newer HW devices Documentation: Add section about CPU vulnerabilities for Spectre Documentation: platform: Delete x86-laptop-drivers.txt docs: Note that :c:func: should no longer be used ...
210 lines
5.7 KiB
ReStructuredText
210 lines
5.7 KiB
ReStructuredText
================
|
|
ARM64 ELF hwcaps
|
|
================
|
|
|
|
This document describes the usage and semantics of the arm64 ELF hwcaps.
|
|
|
|
|
|
1. Introduction
|
|
---------------
|
|
|
|
Some hardware or software features are only available on some CPU
|
|
implementations, and/or with certain kernel configurations, but have no
|
|
architected discovery mechanism available to userspace code at EL0. The
|
|
kernel exposes the presence of these features to userspace through a set
|
|
of flags called hwcaps, exposed in the auxilliary vector.
|
|
|
|
Userspace software can test for features by acquiring the AT_HWCAP or
|
|
AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
|
|
flags are set, e.g.::
|
|
|
|
bool floating_point_is_present(void)
|
|
{
|
|
unsigned long hwcaps = getauxval(AT_HWCAP);
|
|
if (hwcaps & HWCAP_FP)
|
|
return true;
|
|
|
|
return false;
|
|
}
|
|
|
|
Where software relies on a feature described by a hwcap, it should check
|
|
the relevant hwcap flag to verify that the feature is present before
|
|
attempting to make use of the feature.
|
|
|
|
Features cannot be probed reliably through other means. When a feature
|
|
is not available, attempting to use it may result in unpredictable
|
|
behaviour, and is not guaranteed to result in any reliable indication
|
|
that the feature is unavailable, such as a SIGILL.
|
|
|
|
|
|
2. Interpretation of hwcaps
|
|
---------------------------
|
|
|
|
The majority of hwcaps are intended to indicate the presence of features
|
|
which are described by architected ID registers inaccessible to
|
|
userspace code at EL0. These hwcaps are defined in terms of ID register
|
|
fields, and should be interpreted with reference to the definition of
|
|
these fields in the ARM Architecture Reference Manual (ARM ARM).
|
|
|
|
Such hwcaps are described below in the form::
|
|
|
|
Functionality implied by idreg.field == val.
|
|
|
|
Such hwcaps indicate the availability of functionality that the ARM ARM
|
|
defines as being present when idreg.field has value val, but do not
|
|
indicate that idreg.field is precisely equal to val, nor do they
|
|
indicate the absence of functionality implied by other values of
|
|
idreg.field.
|
|
|
|
Other hwcaps may indicate the presence of features which cannot be
|
|
described by ID registers alone. These may be described without
|
|
reference to ID registers, and may refer to other documentation.
|
|
|
|
|
|
3. The hwcaps exposed in AT_HWCAP
|
|
---------------------------------
|
|
|
|
HWCAP_FP
|
|
Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
|
|
|
|
HWCAP_ASIMD
|
|
Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
|
|
|
|
HWCAP_EVTSTRM
|
|
The generic timer is configured to generate events at a frequency of
|
|
approximately 100KHz.
|
|
|
|
HWCAP_AES
|
|
Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
|
|
|
|
HWCAP_PMULL
|
|
Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
|
|
|
|
HWCAP_SHA1
|
|
Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
|
|
|
|
HWCAP_SHA2
|
|
Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
|
|
|
|
HWCAP_CRC32
|
|
Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
|
|
|
|
HWCAP_ATOMICS
|
|
Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
|
|
|
|
HWCAP_FPHP
|
|
Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
|
|
|
|
HWCAP_ASIMDHP
|
|
Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
|
|
|
|
HWCAP_CPUID
|
|
EL0 access to certain ID registers is available, to the extent
|
|
described by Documentation/arm64/cpu-feature-registers.rst.
|
|
|
|
These ID registers may imply the availability of features.
|
|
|
|
HWCAP_ASIMDRDM
|
|
Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
|
|
|
|
HWCAP_JSCVT
|
|
Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
|
|
|
|
HWCAP_FCMA
|
|
Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
|
|
|
|
HWCAP_LRCPC
|
|
Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
|
|
|
|
HWCAP_DCPOP
|
|
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
|
|
|
|
HWCAP2_DCPODP
|
|
|
|
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
|
|
|
|
HWCAP_SHA3
|
|
Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
|
|
|
|
HWCAP_SM3
|
|
Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
|
|
|
|
HWCAP_SM4
|
|
Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
|
|
|
|
HWCAP_ASIMDDP
|
|
Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
|
|
|
|
HWCAP_SHA512
|
|
Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
|
|
|
|
HWCAP_SVE
|
|
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
|
|
|
|
HWCAP2_SVE2
|
|
|
|
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
|
|
|
|
HWCAP2_SVEAES
|
|
|
|
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
|
|
|
|
HWCAP2_SVEPMULL
|
|
|
|
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
|
|
|
|
HWCAP2_SVEBITPERM
|
|
|
|
Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
|
|
|
|
HWCAP2_SVESHA3
|
|
|
|
Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
|
|
|
|
HWCAP2_SVESM4
|
|
|
|
Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
|
|
|
|
HWCAP_ASIMDFHM
|
|
Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
|
|
|
|
HWCAP_DIT
|
|
Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
|
|
|
|
HWCAP_USCAT
|
|
Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
|
|
|
|
HWCAP_ILRCPC
|
|
Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
|
|
|
|
HWCAP_FLAGM
|
|
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
|
|
|
|
HWCAP2_FLAGM2
|
|
|
|
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
|
|
|
|
HWCAP_SSBS
|
|
Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
|
|
|
|
HWCAP_PACA
|
|
Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
|
|
ID_AA64ISAR1_EL1.API == 0b0001, as described by
|
|
Documentation/arm64/pointer-authentication.rst.
|
|
|
|
HWCAP_PACG
|
|
Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
|
|
ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
|
|
Documentation/arm64/pointer-authentication.rst.
|
|
|
|
HWCAP2_FRINT
|
|
|
|
Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
|
|
|
|
|
|
4. Unused AT_HWCAP bits
|
|
-----------------------
|
|
|
|
For interoperation with userspace, the kernel guarantees that bits 62
|
|
and 63 of AT_HWCAP will always be returned as 0.
|