arch/arm64/include/asm/cpufeature.h
Source file repositories/reference/linux-study-clean/arch/arm64/include/asm/cpufeature.h
File Facts
- System
- Linux kernel
- Corpus path
arch/arm64/include/asm/cpufeature.h- Extension
.h- Size
- 34280 bytes
- Lines
- 1091
- Domain
- Architecture Layer
- Bucket
- arch/arm64
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
asm/alternative-macros.hasm/cpucaps.hasm/cputype.hasm/hwcap.hasm/sysreg.hlinux/bug.hlinux/jump_label.hlinux/kernel.hlinux/cpumask.h
Detected Declarations
struct arm64_ftr_bitsstruct arm64_ftr_overridestruct arm64_ftr_regstruct arm64_cpu_capabilitiesenum ftr_typefunction cpucap_default_scopefunction cpucap_match_all_early_cpusfunction multiplefunction is_vhe_hyp_codefunction is_nvhe_hyp_codefunction is_hyp_codefunction boot_capabilities_finalizedfunction system_capabilities_finalizedfunction cpus_have_capfunction cpus_have_final_boot_capfunction cpus_have_final_capfunction cpuid_feature_extract_signed_field_widthfunction cpuid_feature_extract_signed_fieldfunction cpuid_feature_extract_unsigned_field_widthfunction cpuid_feature_extract_unsigned_fieldfunction arm64_ftr_maskfunction arm64_ftr_reg_user_valuefunction cpuid_feature_extract_field_widthfunction cpuid_feature_extract_fieldfunction arm64_ftr_valuefunction id_aa64mmfr0_mixed_endian_el0function id_aa64pfr0_32bit_el1function id_aa64pfr0_32bit_el0function id_aa64pfr0_svefunction id_aa64pfr1_smefunction id_aa64pfr0_mpamfunction id_aa64pfr1_mpamfracfunction id_aa64pfr1_mtefunction cpu_supports_mixed_endian_el0function supports_csv2p3function supports_clearbhbfunction system_supports_32bit_el0function system_supports_4kb_granulefunction system_supports_64kb_granulefunction system_supports_16kb_granulefunction system_supports_mixed_endian_el0function system_supports_mixed_endianfunction system_supports_fpsimdfunction system_uses_hw_panfunction system_uses_ttbr0_panfunction system_supports_svefunction system_supports_smefunction system_supports_sme2
Annotated Snippet
struct arm64_ftr_bits {
bool sign; /* Value is signed ? */
bool visible;
bool strict; /* CPU Sanity check: strict matching required ? */
enum ftr_type type;
u8 shift;
u8 width;
s64 safe_val; /* safe value for FTR_EXACT features */
};
/*
* Describe the early feature override to the core override code:
*
* @val Values that are to be merged into the final
* sanitised value of the register. Only the bitfields
* set to 1 in @mask are valid
* @mask Mask of the features that are overridden by @val
*
* A @mask field set to full-1 indicates that the corresponding field
* in @val is a valid override.
*
* A @mask field set to full-0 with the corresponding @val field set
* to full-0 denotes that this field has no override
*
* A @mask field set to full-0 with the corresponding @val field set
* to full-1 denotes that this field has an invalid override.
*/
struct arm64_ftr_override {
u64 val;
u64 mask;
};
/*
* @arm64_ftr_reg - Feature register
* @strict_mask Bits which should match across all CPUs for sanity.
* @sys_val Safe value across the CPUs (system view)
*/
struct arm64_ftr_reg {
const char *name;
u64 strict_mask;
u64 user_mask;
u64 sys_val;
u64 user_val;
struct arm64_ftr_override *override;
const struct arm64_ftr_bits *ftr_bits;
};
extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
/*
* CPU capabilities:
*
* We use arm64_cpu_capabilities to represent system features, errata work
* arounds (both used internally by kernel and tracked in system_cpucaps) and
* ELF HWCAPs (which are exposed to user).
*
* To support systems with heterogeneous CPUs, we need to make sure that we
* detect the capabilities correctly on the system and take appropriate
* measures to ensure there are no incompatibilities.
*
* This comment tries to explain how we treat the capabilities.
* Each capability has the following list of attributes :
*
* 1) Scope of Detection : The system detects a given capability by
* performing some checks at runtime. This could be, e.g, checking the
* value of a field in CPU ID feature register or checking the cpu
* model. The capability provides a call back ( @matches() ) to
* perform the check. Scope defines how the checks should be performed.
* There are three cases:
*
* a) SCOPE_LOCAL_CPU: check all the CPUs and "detect" if at least one
* matches. This implies, we have to run the check on all the
* booting CPUs, until the system decides that state of the
* capability is finalised. (See section 2 below)
* Or
* b) SCOPE_SYSTEM: check all the CPUs and "detect" if all the CPUs
* matches. This implies, we run the check only once, when the
* system decides to finalise the state of the capability. If the
* capability relies on a field in one of the CPU ID feature
* registers, we use the sanitised value of the register from the
* CPU feature infrastructure to make the decision.
* Or
* c) SCOPE_BOOT_CPU: Check only on the primary boot CPU to detect the
* feature. This category is for features that are "finalised"
* (or used) by the kernel very early even before the SMP cpus
* are brought up.
*
* The process of detection is usually denoted by "update" capability
* state in the code.
*
Annotation
- Immediate include surface: `asm/alternative-macros.h`, `asm/cpucaps.h`, `asm/cputype.h`, `asm/hwcap.h`, `asm/sysreg.h`, `linux/bug.h`, `linux/jump_label.h`, `linux/kernel.h`.
- Detected declarations: `struct arm64_ftr_bits`, `struct arm64_ftr_override`, `struct arm64_ftr_reg`, `struct arm64_cpu_capabilities`, `enum ftr_type`, `function cpucap_default_scope`, `function cpucap_match_all_early_cpus`, `function multiple`, `function is_vhe_hyp_code`, `function is_nvhe_hyp_code`.
- Atlas domain: Architecture Layer / arch/arm64.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.