forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kern…
…el/git/arm64/linux Pull arm64 updates from Will Deacon: - Errata workarounds for Qualcomm's Falkor CPU - Qualcomm L2 Cache PMU driver - Qualcomm SMCCC firmware quirk - Support for DEBUG_VIRTUAL - CPU feature detection for userspace via MRS emulation - Preliminary work for the Statistical Profiling Extension - Misc cleanups and non-critical fixes * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (74 commits) arm64/kprobes: consistently handle MRS/MSR with XZR arm64: cpufeature: correctly handle MRS to XZR arm64: traps: correctly handle MRS/MSR with XZR arm64: ptrace: add XZR-safe regs accessors arm64: include asm/assembler.h in entry-ftrace.S arm64: fix warning about swapper_pg_dir overflow arm64: Work around Falkor erratum 1003 arm64: head.S: Enable EL1 (host) access to SPE when entered at EL2 arm64: arch_timer: document Hisilicon erratum 161010101 arm64: use is_vmalloc_addr arm64: use linux/sizes.h for constants arm64: uaccess: consistently check object sizes perf: add qcom l2 cache perf events driver arm64: remove wrong CONFIG_PROC_SYSCTL ifdef ARM: smccc: Update HVC comment to describe new quirk parameter arm64: do not trace atomic operations ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device() ACPI/IORT: Fix iort_node_get_id() mapping entries indexing arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA perf: xgene: Include module.h ...
- Loading branch information
Showing
85 changed files
with
2,396 additions
and
439 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,240 @@ | ||
ARM64 CPU Feature Registers | ||
=========================== | ||
|
||
Author: Suzuki K Poulose <[email protected]> | ||
|
||
|
||
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 | ||
heterogeneous system, this could be racy (just like getcpu()). The | ||
process could be migrated to another CPU by the time it uses the | ||
register value, unless the CPU affinity is set. Hence, there is no | ||
guarantee that the value reflects the processor that it is | ||
currently executing on. The REVIDR is not exposed due to this | ||
constraint, as REVIDR makes sense only in conjunction with the | ||
MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs | ||
at: | ||
|
||
/sys/devices/system/cpu/cpu$ID/regs/identification/ | ||
\- midr | ||
\- revidr | ||
|
||
3. Implementation | ||
-------------------- | ||
|
||
The infrastructure is built on the emulation of the 'MRS' instruction. | ||
Accessing a restricted system register from an application generates an | ||
exception and ends up in SIGILL being delivered to the process. | ||
The infrastructure hooks into the exception handler and emulates the | ||
operation if the source belongs to the supported system register space. | ||
|
||
The infrastructure emulates only the following system register space: | ||
Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7 | ||
|
||
(See Table C5-6 'System instruction encodings for non-Debug System | ||
register accesses' in ARMv8 ARM DDI 0487A.h, for the list of | ||
registers). | ||
|
||
The following rules are applied to the value returned by the | ||
infrastructure: | ||
|
||
a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0. | ||
b) The value of a reserved field is populated with the reserved | ||
value as defined by the architecture. | ||
c) The value of a 'visible' field holds the system wide safe value | ||
for the particular feature (except for MIDR_EL1, see section 4). | ||
d) All other fields (i.e, invisible fields) are set to indicate | ||
the feature is missing (as defined by the architecture). | ||
|
||
4. List of registers with visible features | ||
------------------------------------------- | ||
|
||
1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0 | ||
x--------------------------------------------------x | ||
| Name | bits | visible | | ||
|--------------------------------------------------| | ||
| RES0 | [63-32] | n | | ||
|--------------------------------------------------| | ||
| RDM | [31-28] | y | | ||
|--------------------------------------------------| | ||
| ATOMICS | [23-20] | y | | ||
|--------------------------------------------------| | ||
| CRC32 | [19-16] | y | | ||
|--------------------------------------------------| | ||
| SHA2 | [15-12] | y | | ||
|--------------------------------------------------| | ||
| SHA1 | [11-8] | y | | ||
|--------------------------------------------------| | ||
| AES | [7-4] | y | | ||
|--------------------------------------------------| | ||
| RES0 | [3-0] | n | | ||
x--------------------------------------------------x | ||
|
||
|
||
2) ID_AA64PFR0_EL1 - Processor Feature Register 0 | ||
x--------------------------------------------------x | ||
| Name | bits | visible | | ||
|--------------------------------------------------| | ||
| RES0 | [63-28] | n | | ||
|--------------------------------------------------| | ||
| GIC | [27-24] | n | | ||
|--------------------------------------------------| | ||
| AdvSIMD | [23-20] | y | | ||
|--------------------------------------------------| | ||
| FP | [19-16] | y | | ||
|--------------------------------------------------| | ||
| EL3 | [15-12] | n | | ||
|--------------------------------------------------| | ||
| EL2 | [11-8] | n | | ||
|--------------------------------------------------| | ||
| EL1 | [7-4] | n | | ||
|--------------------------------------------------| | ||
| EL0 | [3-0] | n | | ||
x--------------------------------------------------x | ||
|
||
|
||
3) MIDR_EL1 - Main ID Register | ||
x--------------------------------------------------x | ||
| Name | bits | visible | | ||
|--------------------------------------------------| | ||
| Implementer | [31-24] | y | | ||
|--------------------------------------------------| | ||
| Variant | [23-20] | y | | ||
|--------------------------------------------------| | ||
| Architecture | [19-16] | y | | ||
|--------------------------------------------------| | ||
| PartNum | [15-4] | y | | ||
|--------------------------------------------------| | ||
| Revision | [3-0] | y | | ||
x--------------------------------------------------x | ||
|
||
NOTE: The 'visible' fields of MIDR_EL1 will contain the value | ||
as available on the CPU where it is fetched and is not a system | ||
wide safe value. | ||
|
||
Appendix I: Example | ||
--------------------------- | ||
|
||
/* | ||
* Sample program to demonstrate the MRS emulation ABI. | ||
* | ||
* Copyright (C) 2015-2016, ARM Ltd | ||
* | ||
* Author: Suzuki K Poulose <[email protected]> | ||
* | ||
* This program is free software; you can redistribute it and/or modify | ||
* it under the terms of the GNU General Public License version 2 as | ||
* published by the Free Software Foundation. | ||
* | ||
* This program is distributed in the hope that it will be useful, | ||
* but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
* GNU General Public License for more details. | ||
* This program is free software; you can redistribute it and/or modify | ||
* it under the terms of the GNU General Public License version 2 as | ||
* published by the Free Software Foundation. | ||
* | ||
* This program is distributed in the hope that it will be useful, | ||
* but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
* GNU General Public License for more details. | ||
*/ | ||
|
||
#include <asm/hwcap.h> | ||
#include <stdio.h> | ||
#include <sys/auxv.h> | ||
|
||
#define get_cpu_ftr(id) ({ \ | ||
unsigned long __val; \ | ||
asm("mrs %0, "#id : "=r" (__val)); \ | ||
printf("%-20s: 0x%016lx\n", #id, __val); \ | ||
}) | ||
|
||
int main(void) | ||
{ | ||
|
||
if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) { | ||
fputs("CPUID registers unavailable\n", stderr); | ||
return 1; | ||
} | ||
|
||
get_cpu_ftr(ID_AA64ISAR0_EL1); | ||
get_cpu_ftr(ID_AA64ISAR1_EL1); | ||
get_cpu_ftr(ID_AA64MMFR0_EL1); | ||
get_cpu_ftr(ID_AA64MMFR1_EL1); | ||
get_cpu_ftr(ID_AA64PFR0_EL1); | ||
get_cpu_ftr(ID_AA64PFR1_EL1); | ||
get_cpu_ftr(ID_AA64DFR0_EL1); | ||
get_cpu_ftr(ID_AA64DFR1_EL1); | ||
|
||
get_cpu_ftr(MIDR_EL1); | ||
get_cpu_ftr(MPIDR_EL1); | ||
get_cpu_ftr(REVIDR_EL1); | ||
|
||
#if 0 | ||
/* Unexposed register access causes SIGILL */ | ||
get_cpu_ftr(ID_MMFR0_EL1); | ||
#endif | ||
|
||
return 0; | ||
} | ||
|
||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
Qualcomm Technologies Level-2 Cache Performance Monitoring Unit (PMU) | ||
===================================================================== | ||
|
||
This driver supports the L2 cache clusters found in Qualcomm Technologies | ||
Centriq SoCs. There are multiple physical L2 cache clusters, each with their | ||
own PMU. Each cluster has one or more CPUs associated with it. | ||
|
||
There is one logical L2 PMU exposed, which aggregates the results from | ||
the physical PMUs. | ||
|
||
The driver provides a description of its available events and configuration | ||
options in sysfs, see /sys/devices/l2cache_0. | ||
|
||
The "format" directory describes the format of the events. | ||
|
||
Events can be envisioned as a 2-dimensional array. Each column represents | ||
a group of events. There are 8 groups. Only one entry from each | ||
group can be in use at a time. If multiple events from the same group | ||
are specified, the conflicting events cannot be counted at the same time. | ||
|
||
Events are specified as 0xCCG, where CC is 2 hex digits specifying | ||
the code (array row) and G specifies the group (column) 0-7. | ||
|
||
In addition there is a cycle counter event specified by the value 0xFE | ||
which is outside the above scheme. | ||
|
||
The driver provides a "cpumask" sysfs attribute which contains a mask | ||
consisting of one CPU per cluster which will be used to handle all the PMU | ||
events on that cluster. | ||
|
||
Examples for use with perf: | ||
|
||
perf stat -e l2cache_0/config=0x001/,l2cache_0/config=0x042/ -a sleep 1 | ||
|
||
perf stat -e l2cache_0/config=0xfe/ -C 2 sleep 1 | ||
|
||
The driver does not support sampling, therefore "perf record" will | ||
not work. Per-task perf sessions are not supported. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.