2019-06-04 08:11:33 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2014-03-04 01:10:04 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2014 Linaro Ltd. <ard.biesheuvel@linaro.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __ASM_CPUFEATURE_H
|
|
|
|
#define __ASM_CPUFEATURE_H
|
|
|
|
|
2016-11-03 18:34:34 +00:00
|
|
|
#include <asm/cpucaps.h>
|
2018-03-26 14:12:44 +00:00
|
|
|
#include <asm/cputype.h>
|
2014-03-04 01:10:04 +00:00
|
|
|
#include <asm/hwcap.h>
|
2015-10-19 13:24:42 +00:00
|
|
|
#include <asm/sysreg.h>
|
2014-03-04 01:10:04 +00:00
|
|
|
|
2019-04-09 09:52:40 +00:00
|
|
|
#define MAX_CPU_FEATURES 64
|
|
|
|
#define cpu_feature(x) KERNEL_HWCAP_ ## x
|
2014-03-04 01:10:04 +00:00
|
|
|
|
2014-11-14 15:54:10 +00:00
|
|
|
#ifndef __ASSEMBLY__
|
2014-11-14 15:54:07 +00:00
|
|
|
|
2016-11-08 13:56:20 +00:00
|
|
|
#include <linux/bug.h>
|
|
|
|
#include <linux/jump_label.h>
|
2015-04-30 17:55:50 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
2017-01-09 17:28:27 +00:00
|
|
|
/*
|
|
|
|
* CPU feature register tracking
|
|
|
|
*
|
|
|
|
* The safe value of a CPUID feature field is dependent on the implications
|
|
|
|
* of the values assigned to it by the architecture. Based on the relationship
|
|
|
|
* between the values, the features are classified into 3 types - LOWER_SAFE,
|
|
|
|
* HIGHER_SAFE and EXACT.
|
|
|
|
*
|
|
|
|
* The lowest value of all the CPUs is chosen for LOWER_SAFE and highest
|
|
|
|
* for HIGHER_SAFE. It is expected that all CPUs have the same value for
|
|
|
|
* a field when EXACT is specified, failing which, the safe value specified
|
|
|
|
* in the table is chosen.
|
|
|
|
*/
|
|
|
|
|
2015-10-19 13:24:45 +00:00
|
|
|
enum ftr_type {
|
2019-07-30 14:40:20 +00:00
|
|
|
FTR_EXACT, /* Use a predefined safe value */
|
|
|
|
FTR_LOWER_SAFE, /* Smaller value is safe */
|
|
|
|
FTR_HIGHER_SAFE, /* Bigger value is safe */
|
|
|
|
FTR_HIGHER_OR_ZERO_SAFE, /* Bigger value is safe, but 0 is biggest */
|
2015-10-19 13:24:45 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define FTR_STRICT true /* SANITY check strict matching required */
|
|
|
|
#define FTR_NONSTRICT false /* SANITY check ignored */
|
|
|
|
|
2015-11-18 17:08:57 +00:00
|
|
|
#define FTR_SIGNED true /* Value should be treated as signed */
|
|
|
|
#define FTR_UNSIGNED false /* Value should be treated as unsigned */
|
|
|
|
|
2017-01-09 17:28:30 +00:00
|
|
|
#define FTR_VISIBLE true /* Feature visible to the user space */
|
|
|
|
#define FTR_HIDDEN false /* Feature is hidden from the user */
|
|
|
|
|
2017-12-14 14:03:44 +00:00
|
|
|
#define FTR_VISIBLE_IF_IS_ENABLED(config) \
|
|
|
|
(IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
|
|
|
|
|
2015-10-19 13:24:45 +00:00
|
|
|
struct arm64_ftr_bits {
|
2015-11-18 17:08:57 +00:00
|
|
|
bool sign; /* Value is signed ? */
|
2017-01-09 17:28:30 +00:00
|
|
|
bool visible;
|
2015-11-18 17:08:57 +00:00
|
|
|
bool strict; /* CPU Sanity check: strict matching required ? */
|
2015-10-19 13:24:45 +00:00
|
|
|
enum ftr_type type;
|
|
|
|
u8 shift;
|
|
|
|
u8 width;
|
2016-09-09 13:07:08 +00:00
|
|
|
s64 safe_val; /* safe value for FTR_EXACT features */
|
2015-10-19 13:24:45 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* @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 {
|
2016-08-31 10:31:08 +00:00
|
|
|
const char *name;
|
|
|
|
u64 strict_mask;
|
2017-01-09 17:28:30 +00:00
|
|
|
u64 user_mask;
|
2016-08-31 10:31:08 +00:00
|
|
|
u64 sys_val;
|
2017-01-09 17:28:30 +00:00
|
|
|
u64 user_val;
|
2016-08-31 10:31:08 +00:00
|
|
|
const struct arm64_ftr_bits *ftr_bits;
|
2015-10-19 13:24:45 +00:00
|
|
|
};
|
|
|
|
|
2016-08-31 10:31:10 +00:00
|
|
|
extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
|
|
|
|
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
/*
|
|
|
|
* CPU capabilities:
|
|
|
|
*
|
|
|
|
* We use arm64_cpu_capabilities to represent system features, errata work
|
|
|
|
* arounds (both used internally by kernel and tracked in cpu_hwcaps) 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.
|
2018-03-26 14:12:41 +00:00
|
|
|
* There are three cases:
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
*
|
|
|
|
* 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.
|
2018-03-26 14:12:41 +00:00
|
|
|
* 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.
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
*
|
|
|
|
* The process of detection is usually denoted by "update" capability
|
|
|
|
* state in the code.
|
|
|
|
*
|
|
|
|
* 2) Finalise the state : The kernel should finalise the state of a
|
|
|
|
* capability at some point during its execution and take necessary
|
|
|
|
* actions if any. Usually, this is done, after all the boot-time
|
|
|
|
* enabled CPUs are brought up by the kernel, so that it can make
|
|
|
|
* better decision based on the available set of CPUs. However, there
|
|
|
|
* are some special cases, where the action is taken during the early
|
|
|
|
* boot by the primary boot CPU. (e.g, running the kernel at EL2 with
|
|
|
|
* Virtualisation Host Extensions). The kernel usually disallows any
|
|
|
|
* changes to the state of a capability once it finalises the capability
|
|
|
|
* and takes any action, as it may be impossible to execute the actions
|
|
|
|
* safely. A CPU brought up after a capability is "finalised" is
|
|
|
|
* referred to as "Late CPU" w.r.t the capability. e.g, all secondary
|
|
|
|
* CPUs are treated "late CPUs" for capabilities determined by the boot
|
|
|
|
* CPU.
|
|
|
|
*
|
2018-03-26 14:12:41 +00:00
|
|
|
* At the moment there are two passes of finalising the capabilities.
|
|
|
|
* a) Boot CPU scope capabilities - Finalised by primary boot CPU via
|
|
|
|
* setup_boot_cpu_capabilities().
|
|
|
|
* b) Everything except (a) - Run via setup_system_capabilities().
|
|
|
|
*
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
* 3) Verification: When a CPU is brought online (e.g, by user or by the
|
|
|
|
* kernel), the kernel should make sure that it is safe to use the CPU,
|
|
|
|
* by verifying that the CPU is compliant with the state of the
|
|
|
|
* capabilities finalised already. This happens via :
|
|
|
|
*
|
|
|
|
* secondary_start_kernel()-> check_local_cpu_capabilities()
|
|
|
|
*
|
|
|
|
* As explained in (2) above, capabilities could be finalised at
|
2018-03-26 14:12:41 +00:00
|
|
|
* different points in the execution. Each newly booted CPU is verified
|
|
|
|
* against the capabilities that have been finalised by the time it
|
|
|
|
* boots.
|
|
|
|
*
|
|
|
|
* a) SCOPE_BOOT_CPU : All CPUs are verified against the capability
|
|
|
|
* except for the primary boot CPU.
|
|
|
|
*
|
|
|
|
* b) SCOPE_LOCAL_CPU, SCOPE_SYSTEM: All CPUs hotplugged on by the
|
|
|
|
* user after the kernel boot are verified against the capability.
|
|
|
|
*
|
|
|
|
* If there is a conflict, the kernel takes an action, based on the
|
|
|
|
* severity (e.g, a CPU could be prevented from booting or cause a
|
|
|
|
* kernel panic). The CPU is allowed to "affect" the state of the
|
|
|
|
* capability, if it has not been finalised already. See section 5
|
|
|
|
* for more details on conflicts.
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
*
|
|
|
|
* 4) Action: As mentioned in (2), the kernel can take an action for each
|
|
|
|
* detected capability, on all CPUs on the system. Appropriate actions
|
|
|
|
* include, turning on an architectural feature, modifying the control
|
|
|
|
* registers (e.g, SCTLR, TCR etc.) or patching the kernel via
|
|
|
|
* alternatives. The kernel patching is batched and performed at later
|
|
|
|
* point. The actions are always initiated only after the capability
|
|
|
|
* is finalised. This is usally denoted by "enabling" the capability.
|
|
|
|
* The actions are initiated as follows :
|
|
|
|
* a) Action is triggered on all online CPUs, after the capability is
|
|
|
|
* finalised, invoked within the stop_machine() context from
|
|
|
|
* enable_cpu_capabilitie().
|
|
|
|
*
|
|
|
|
* b) Any late CPU, brought up after (1), the action is triggered via:
|
|
|
|
*
|
|
|
|
* check_local_cpu_capabilities() -> verify_local_cpu_capabilities()
|
|
|
|
*
|
2018-03-26 14:12:32 +00:00
|
|
|
* 5) Conflicts: Based on the state of the capability on a late CPU vs.
|
|
|
|
* the system state, we could have the following combinations :
|
|
|
|
*
|
|
|
|
* x-----------------------------x
|
|
|
|
* | Type | System | Late CPU |
|
|
|
|
* |-----------------------------|
|
|
|
|
* | a | y | n |
|
|
|
|
* |-----------------------------|
|
|
|
|
* | b | n | y |
|
|
|
|
* x-----------------------------x
|
|
|
|
*
|
|
|
|
* Two separate flag bits are defined to indicate whether each kind of
|
|
|
|
* conflict can be allowed:
|
|
|
|
* ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU - Case(a) is allowed
|
|
|
|
* ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU - Case(b) is allowed
|
|
|
|
*
|
|
|
|
* Case (a) is not permitted for a capability that the system requires
|
|
|
|
* all CPUs to have in order for the capability to be enabled. This is
|
|
|
|
* typical for capabilities that represent enhanced functionality.
|
|
|
|
*
|
|
|
|
* Case (b) is not permitted for a capability that must be enabled
|
|
|
|
* during boot if any CPU in the system requires it in order to run
|
|
|
|
* safely. This is typical for erratum work arounds that cannot be
|
|
|
|
* enabled after the corresponding capability is finalised.
|
|
|
|
*
|
|
|
|
* In some non-typical cases either both (a) and (b), or neither,
|
|
|
|
* should be permitted. This can be described by including neither
|
|
|
|
* or both flags in the capability's type field.
|
2020-03-13 09:04:54 +00:00
|
|
|
*
|
|
|
|
* In case of a conflict, the CPU is prevented from booting. If the
|
|
|
|
* ARM64_CPUCAP_PANIC_ON_CONFLICT flag is specified for the capability,
|
|
|
|
* then a kernel panic is triggered.
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
2018-03-26 14:12:41 +00:00
|
|
|
/*
|
|
|
|
* Decide how the capability is detected.
|
|
|
|
* On any local CPU vs System wide vs the primary boot CPU
|
|
|
|
*/
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
#define ARM64_CPUCAP_SCOPE_LOCAL_CPU ((u16)BIT(0))
|
|
|
|
#define ARM64_CPUCAP_SCOPE_SYSTEM ((u16)BIT(1))
|
2018-03-26 14:12:41 +00:00
|
|
|
/*
|
|
|
|
* The capabilitiy is detected on the Boot CPU and is used by kernel
|
|
|
|
* during early boot. i.e, the capability should be "detected" and
|
|
|
|
* "enabled" as early as possibly on all booting CPUs.
|
|
|
|
*/
|
|
|
|
#define ARM64_CPUCAP_SCOPE_BOOT_CPU ((u16)BIT(2))
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
#define ARM64_CPUCAP_SCOPE_MASK \
|
|
|
|
(ARM64_CPUCAP_SCOPE_SYSTEM | \
|
2018-03-26 14:12:41 +00:00
|
|
|
ARM64_CPUCAP_SCOPE_LOCAL_CPU | \
|
|
|
|
ARM64_CPUCAP_SCOPE_BOOT_CPU)
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
|
|
|
|
#define SCOPE_SYSTEM ARM64_CPUCAP_SCOPE_SYSTEM
|
|
|
|
#define SCOPE_LOCAL_CPU ARM64_CPUCAP_SCOPE_LOCAL_CPU
|
2018-03-26 14:12:41 +00:00
|
|
|
#define SCOPE_BOOT_CPU ARM64_CPUCAP_SCOPE_BOOT_CPU
|
2018-03-26 14:12:34 +00:00
|
|
|
#define SCOPE_ALL ARM64_CPUCAP_SCOPE_MASK
|
2016-04-22 11:25:31 +00:00
|
|
|
|
2018-03-26 14:12:32 +00:00
|
|
|
/*
|
|
|
|
* Is it permitted for a late CPU to have this capability when system
|
|
|
|
* hasn't already enabled it ?
|
|
|
|
*/
|
|
|
|
#define ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU ((u16)BIT(4))
|
|
|
|
/* Is it safe for a late CPU to miss this capability when system has it */
|
|
|
|
#define ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU ((u16)BIT(5))
|
2020-03-13 09:04:54 +00:00
|
|
|
/* Panic when a conflict is detected */
|
|
|
|
#define ARM64_CPUCAP_PANIC_ON_CONFLICT ((u16)BIT(6))
|
2018-03-26 14:12:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* CPU errata workarounds that need to be enabled at boot time if one or
|
|
|
|
* more CPUs in the system requires it. When one of these capabilities
|
|
|
|
* has been enabled, it is safe to allow any CPU to boot that doesn't
|
|
|
|
* require the workaround. However, it is not safe if a "late" CPU
|
|
|
|
* requires a workaround and the system hasn't enabled it already.
|
|
|
|
*/
|
|
|
|
#define ARM64_CPUCAP_LOCAL_CPU_ERRATUM \
|
|
|
|
(ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU)
|
|
|
|
/*
|
|
|
|
* CPU feature detected at boot time based on system-wide value of a
|
|
|
|
* feature. It is safe for a late CPU to have this feature even though
|
2018-06-15 10:36:43 +00:00
|
|
|
* the system hasn't enabled it, although the feature will not be used
|
2018-03-26 14:12:32 +00:00
|
|
|
* by Linux in this case. If the system has enabled this feature already,
|
|
|
|
* then every late CPU must have it.
|
|
|
|
*/
|
|
|
|
#define ARM64_CPUCAP_SYSTEM_FEATURE \
|
|
|
|
(ARM64_CPUCAP_SCOPE_SYSTEM | ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU)
|
2018-03-26 14:12:39 +00:00
|
|
|
/*
|
|
|
|
* CPU feature detected at boot time based on feature of one or more CPUs.
|
|
|
|
* All possible conflicts for a late CPU are ignored.
|
|
|
|
*/
|
|
|
|
#define ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE \
|
|
|
|
(ARM64_CPUCAP_SCOPE_LOCAL_CPU | \
|
|
|
|
ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU | \
|
|
|
|
ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU)
|
2018-03-26 14:12:32 +00:00
|
|
|
|
2018-03-26 14:12:40 +00:00
|
|
|
/*
|
|
|
|
* CPU feature detected at boot time, on one or more CPUs. A late CPU
|
|
|
|
* is not allowed to have the capability when the system doesn't have it.
|
|
|
|
* It is Ok for a late CPU to miss the feature.
|
|
|
|
*/
|
|
|
|
#define ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE \
|
|
|
|
(ARM64_CPUCAP_SCOPE_LOCAL_CPU | \
|
|
|
|
ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU)
|
|
|
|
|
2018-03-26 14:12:42 +00:00
|
|
|
/*
|
|
|
|
* CPU feature used early in the boot based on the boot CPU. All secondary
|
2020-03-13 09:04:54 +00:00
|
|
|
* CPUs must match the state of the capability as detected by the boot CPU. In
|
|
|
|
* case of a conflict, a kernel panic is triggered.
|
2018-03-26 14:12:42 +00:00
|
|
|
*/
|
2020-03-13 09:04:54 +00:00
|
|
|
#define ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE \
|
|
|
|
(ARM64_CPUCAP_SCOPE_BOOT_CPU | ARM64_CPUCAP_PANIC_ON_CONFLICT)
|
2018-03-26 14:12:42 +00:00
|
|
|
|
2020-03-13 09:04:55 +00:00
|
|
|
/*
|
|
|
|
* CPU feature used early in the boot based on the boot CPU. It is safe for a
|
|
|
|
* late CPU to have this feature even though the boot CPU hasn't enabled it,
|
|
|
|
* although the feature will not be used by Linux in this case. If the boot CPU
|
|
|
|
* has enabled this feature already, then every late CPU must have it.
|
2018-03-26 14:12:42 +00:00
|
|
|
*/
|
2020-03-13 09:04:55 +00:00
|
|
|
#define ARM64_CPUCAP_BOOT_CPU_FEATURE \
|
|
|
|
(ARM64_CPUCAP_SCOPE_BOOT_CPU | ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU)
|
2018-03-26 14:12:42 +00:00
|
|
|
|
2015-03-27 13:09:23 +00:00
|
|
|
struct arm64_cpu_capabilities {
|
|
|
|
const char *desc;
|
|
|
|
u16 capability;
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
u16 type;
|
2016-04-22 11:25:31 +00:00
|
|
|
bool (*matches)(const struct arm64_cpu_capabilities *caps, int scope);
|
2018-03-26 14:12:28 +00:00
|
|
|
/*
|
2019-08-08 14:05:54 +00:00
|
|
|
* Take the appropriate actions to configure this capability
|
|
|
|
* for this CPU. If the capability is detected by the kernel
|
|
|
|
* this will be called on all the CPUs in the system,
|
|
|
|
* including the hotplugged CPUs, regardless of whether the
|
|
|
|
* capability is available on that specific CPU. This is
|
|
|
|
* useful for some capabilities (e.g, working around CPU
|
|
|
|
* errata), where all the CPUs must take some action (e.g,
|
|
|
|
* changing system control/configuration). Thus, if an action
|
|
|
|
* is required only if the CPU has the capability, then the
|
|
|
|
* routine must check it before taking any action.
|
2018-03-26 14:12:28 +00:00
|
|
|
*/
|
|
|
|
void (*cpu_enable)(const struct arm64_cpu_capabilities *cap);
|
2015-03-27 13:09:23 +00:00
|
|
|
union {
|
|
|
|
struct { /* To be used for erratum handling only */
|
2018-03-26 14:12:44 +00:00
|
|
|
struct midr_range midr_range;
|
2018-03-06 17:15:34 +00:00
|
|
|
const struct arm64_midr_revidr {
|
|
|
|
u32 midr_rv; /* revision/variant */
|
|
|
|
u32 revidr_mask;
|
|
|
|
} * const fixed_revs;
|
2015-03-27 13:09:23 +00:00
|
|
|
};
|
2015-06-12 11:06:36 +00:00
|
|
|
|
2018-03-26 14:12:45 +00:00
|
|
|
const struct midr_range *midr_range_list;
|
2015-06-12 11:06:36 +00:00
|
|
|
struct { /* Feature register checking */
|
2015-10-19 13:24:51 +00:00
|
|
|
u32 sys_reg;
|
2016-01-26 10:58:15 +00:00
|
|
|
u8 field_pos;
|
|
|
|
u8 min_field_value;
|
|
|
|
u8 hwcap_type;
|
|
|
|
bool sign;
|
2015-10-19 13:24:52 +00:00
|
|
|
unsigned long hwcap;
|
2015-06-12 11:06:36 +00:00
|
|
|
};
|
2015-03-27 13:09:23 +00:00
|
|
|
};
|
2018-12-12 15:53:54 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* An optional list of "matches/cpu_enable" pair for the same
|
|
|
|
* "capability" of the same "type" as described by the parent.
|
|
|
|
* Only matches(), cpu_enable() and fields relevant to these
|
|
|
|
* methods are significant in the list. The cpu_enable is
|
|
|
|
* invoked only if the corresponding entry "matches()".
|
|
|
|
* However, if a cpu_enable() method is associated
|
|
|
|
* with multiple matches(), care should be taken that either
|
|
|
|
* the match criteria are mutually exclusive, or that the
|
|
|
|
* method is robust against being called multiple times.
|
|
|
|
*/
|
|
|
|
const struct arm64_cpu_capabilities *match_list;
|
2015-03-27 13:09:23 +00:00
|
|
|
};
|
|
|
|
|
arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :
1) Detection, i.e scope : A cap could be "detected" either :
- if it is present on at least one CPU (SCOPE_LOCAL_CPU)
Or
- if it is present on all the CPUs (SCOPE_SYSTEM)
2) When is it enabled ? - A cap is treated as "enabled" when the
system takes some action based on whether the capability is detected or
not. e.g, setting some control register, patching the kernel code.
Right now, we treat all caps are enabled at boot-time, after all
the CPUs are brought up by the kernel. But there are certain caps,
which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
and kernel starts using them, even before the secondary CPUs are brought
up. We would need a way to describe this for each capability.
3) Conflict on a late CPU - When a CPU is brought up, it is checked
against the caps that are known to be enabled on the system (via
verify_local_cpu_capabilities()). Based on the state of the capability
on the CPU vs. that of System we could have the following combinations
of conflict.
x-----------------------------x
| Type | System | Late CPU |
------------------------------|
| a | y | n |
------------------------------|
| b | n | y |
x-----------------------------x
Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.
Case (b) is not permitted for errata work arounds which requires some
work around, which cannot be delayed. And we ignore (b) for features.
Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
are too late to enable it (because we change the allocation of ASIDs
etc).
So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.
We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.
As such there is no change in how the capabilities are treated.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 14:12:31 +00:00
|
|
|
static inline int cpucap_default_scope(const struct arm64_cpu_capabilities *cap)
|
|
|
|
{
|
|
|
|
return cap->type & ARM64_CPUCAP_SCOPE_MASK;
|
|
|
|
}
|
|
|
|
|
2018-12-12 15:53:54 +00:00
|
|
|
/*
|
|
|
|
* Generic helper for handling capabilties with multiple (match,enable) pairs
|
|
|
|
* of call backs, sharing the same capability bit.
|
|
|
|
* Iterate over each entry to see if at least one matches.
|
|
|
|
*/
|
|
|
|
static inline bool
|
|
|
|
cpucap_multi_entry_cap_matches(const struct arm64_cpu_capabilities *entry,
|
|
|
|
int scope)
|
|
|
|
{
|
|
|
|
const struct arm64_cpu_capabilities *caps;
|
|
|
|
|
|
|
|
for (caps = entry->match_list; caps->matches; caps++)
|
|
|
|
if (caps->matches(caps, scope))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
arm64: Provide a namespace to NCAPS
Building arm64.allmodconfig leads to the following warning:
usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined
#define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
^
In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0,
from /home/build/work/batch/include/linux/clocksource.h:19,
from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19,
from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27,
from /home/build/work/batch/arch/arm64/include/asm/timex.h:19,
from /home/build/work/batch/include/linux/timex.h:65,
from /home/build/work/batch/include/linux/sched.h:19,
from /home/build/work/batch/arch/arm64/include/asm/compat.h:25,
from /home/build/work/batch/arch/arm64/include/asm/stat.h:23,
from /home/build/work/batch/include/linux/stat.h:5,
from /home/build/work/batch/include/linux/module.h:10,
from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19:
arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition
#define NCAPS 2
So add a ARM64 prefix to avoid such problem.
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-04 01:17:01 +00:00
|
|
|
extern DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
|
2016-09-05 17:25:48 +00:00
|
|
|
extern struct static_key_false cpu_hwcap_keys[ARM64_NCAPS];
|
arm64/cpufeature: don't use mutex in bringup path
Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which
must take the jump_label mutex.
We call cpus_set_cap() in the secondary bringup path, from the idle
thread where interrupts are disabled. Taking a mutex in this path "is a
NONO" regardless of whether it's contended, and something we must avoid.
We didn't spot this until recently, as ___might_sleep() won't warn for
this case until all CPUs have been brought up.
This patch avoids taking the mutex in the secondary bringup path. The
poking of static keys is deferred until enable_cpu_capabilities(), which
runs in a suitable context on the boot CPU. To account for the static
keys being set later, cpus_have_const_cap() is updated to use another
static key to check whether the const cap keys have been initialised,
falling back to the caps bitmap until this is the case.
This means that users of cpus_have_const_cap() gain should only gain a
single additional NOP in the fast path once the const caps are
initialised, but should always see the current cap value.
The hyp code should never dereference the caps array, since the caps are
initialized before we run the module initcall to initialise hyp. A check
is added to the hyp init code to document this requirement.
This change will sidestep a number of issues when the upcoming hotplug
locking rework is merged.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyniger <marc.zyngier@arm.com>
Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-16 14:18:05 +00:00
|
|
|
extern struct static_key_false arm64_const_caps_ready;
|
2014-11-14 15:54:07 +00:00
|
|
|
|
2019-01-31 14:58:53 +00:00
|
|
|
/* ARM64 CAPS + alternative_cb */
|
|
|
|
#define ARM64_NPATCHABLE (ARM64_NCAPS + 1)
|
|
|
|
extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
|
|
|
|
|
2018-11-30 17:18:06 +00:00
|
|
|
#define for_each_available_cap(cap) \
|
|
|
|
for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
|
|
|
|
|
2016-04-22 11:25:32 +00:00
|
|
|
bool this_cpu_has_cap(unsigned int cap);
|
2019-04-09 09:52:41 +00:00
|
|
|
void cpu_set_feature(unsigned int num);
|
|
|
|
bool cpu_have_feature(unsigned int num);
|
|
|
|
unsigned long cpu_get_elf_hwcap(void);
|
|
|
|
unsigned long cpu_get_elf_hwcap2(void);
|
2016-04-22 11:25:32 +00:00
|
|
|
|
2019-04-09 09:52:40 +00:00
|
|
|
#define cpu_set_named_feature(name) cpu_set_feature(cpu_feature(name))
|
|
|
|
#define cpu_have_named_feature(name) cpu_have_feature(cpu_feature(name))
|
2014-03-04 01:10:04 +00:00
|
|
|
|
arm64: cpufeature: add cpus_have_final_cap()
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
We then made use of cpus_have_const_cap() throughout the kernel.
Subsequently, we had to defer updating the static_key associated with
each capability in order to avoid lockdep complaints. To avoid breaking
kernel-wide usage of cpus_have_const_cap(), this was updated to fall
back to the cpu_hwcaps array if called before the static_keys were
updated. As the kvm hyp code was only called later than this, the
fallback is redundant but not functionally harmful. For more details,
see commit:
63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
Today we have more users of cpus_have_const_cap() which are only called
once the relevant static keys are initialized, and it would be
beneficial to avoid the redundant code.
To that end, this patch adds a new cpus_have_final_cap(), helper which
is intend to be used in code which is only run once capabilities have
been finalized, and will never check the cpus_hwcap array. This helps
the compiler to generate better code as it no longer needs to generate
code to address and test the cpus_hwcap array. To help catch misuse,
cpus_have_final_cap() will BUG() if called before capabilities are
finalized.
In hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers. Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-02-21 14:50:21 +00:00
|
|
|
static __always_inline bool system_capabilities_finalized(void)
|
2016-11-08 13:56:20 +00:00
|
|
|
{
|
arm64: cpufeature: add cpus_have_final_cap()
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
We then made use of cpus_have_const_cap() throughout the kernel.
Subsequently, we had to defer updating the static_key associated with
each capability in order to avoid lockdep complaints. To avoid breaking
kernel-wide usage of cpus_have_const_cap(), this was updated to fall
back to the cpu_hwcaps array if called before the static_keys were
updated. As the kvm hyp code was only called later than this, the
fallback is redundant but not functionally harmful. For more details,
see commit:
63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
Today we have more users of cpus_have_const_cap() which are only called
once the relevant static keys are initialized, and it would be
beneficial to avoid the redundant code.
To that end, this patch adds a new cpus_have_final_cap(), helper which
is intend to be used in code which is only run once capabilities have
been finalized, and will never check the cpus_hwcap array. This helps
the compiler to generate better code as it no longer needs to generate
code to address and test the cpus_hwcap array. To help catch misuse,
cpus_have_final_cap() will BUG() if called before capabilities are
finalized.
In hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers. Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-02-21 14:50:21 +00:00
|
|
|
return static_branch_likely(&arm64_const_caps_ready);
|
2016-11-08 13:56:20 +00:00
|
|
|
}
|
|
|
|
|
arm64: cpufeature: add cpus_have_final_cap()
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
We then made use of cpus_have_const_cap() throughout the kernel.
Subsequently, we had to defer updating the static_key associated with
each capability in order to avoid lockdep complaints. To avoid breaking
kernel-wide usage of cpus_have_const_cap(), this was updated to fall
back to the cpu_hwcaps array if called before the static_keys were
updated. As the kvm hyp code was only called later than this, the
fallback is redundant but not functionally harmful. For more details,
see commit:
63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
Today we have more users of cpus_have_const_cap() which are only called
once the relevant static keys are initialized, and it would be
beneficial to avoid the redundant code.
To that end, this patch adds a new cpus_have_final_cap(), helper which
is intend to be used in code which is only run once capabilities have
been finalized, and will never check the cpus_hwcap array. This helps
the compiler to generate better code as it no longer needs to generate
code to address and test the cpus_hwcap array. To help catch misuse,
cpus_have_final_cap() will BUG() if called before capabilities are
finalized.
In hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers. Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-02-21 14:50:21 +00:00
|
|
|
/*
|
|
|
|
* Test for a capability with a runtime check.
|
|
|
|
*
|
|
|
|
* Before the capability is detected, this returns false.
|
|
|
|
*/
|
2014-11-14 15:54:07 +00:00
|
|
|
static inline bool cpus_have_cap(unsigned int num)
|
|
|
|
{
|
arm64: Provide a namespace to NCAPS
Building arm64.allmodconfig leads to the following warning:
usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined
#define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
^
In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0,
from /home/build/work/batch/include/linux/clocksource.h:19,
from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19,
from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27,
from /home/build/work/batch/arch/arm64/include/asm/timex.h:19,
from /home/build/work/batch/include/linux/timex.h:65,
from /home/build/work/batch/include/linux/sched.h:19,
from /home/build/work/batch/arch/arm64/include/asm/compat.h:25,
from /home/build/work/batch/arch/arm64/include/asm/stat.h:23,
from /home/build/work/batch/include/linux/stat.h:5,
from /home/build/work/batch/include/linux/module.h:10,
from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19:
arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition
#define NCAPS 2
So add a ARM64 prefix to avoid such problem.
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-04 01:17:01 +00:00
|
|
|
if (num >= ARM64_NCAPS)
|
2014-11-14 15:54:07 +00:00
|
|
|
return false;
|
2016-11-08 13:56:20 +00:00
|
|
|
return test_bit(num, cpu_hwcaps);
|
2014-11-14 15:54:07 +00:00
|
|
|
}
|
|
|
|
|
arm64: cpufeature: add cpus_have_final_cap()
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
We then made use of cpus_have_const_cap() throughout the kernel.
Subsequently, we had to defer updating the static_key associated with
each capability in order to avoid lockdep complaints. To avoid breaking
kernel-wide usage of cpus_have_const_cap(), this was updated to fall
back to the cpu_hwcaps array if called before the static_keys were
updated. As the kvm hyp code was only called later than this, the
fallback is redundant but not functionally harmful. For more details,
see commit:
63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
Today we have more users of cpus_have_const_cap() which are only called
once the relevant static keys are initialized, and it would be
beneficial to avoid the redundant code.
To that end, this patch adds a new cpus_have_final_cap(), helper which
is intend to be used in code which is only run once capabilities have
been finalized, and will never check the cpus_hwcap array. This helps
the compiler to generate better code as it no longer needs to generate
code to address and test the cpus_hwcap array. To help catch misuse,
cpus_have_final_cap() will BUG() if called before capabilities are
finalized.
In hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers. Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-02-21 14:50:21 +00:00
|
|
|
/*
|
|
|
|
* Test for a capability without a runtime check.
|
|
|
|
*
|
|
|
|
* Before capabilities are finalized, this returns false.
|
|
|
|
* After capabilities are finalized, this is patched to avoid a runtime check.
|
|
|
|
*
|
|
|
|
* @num must be a compile-time constant.
|
|
|
|
*/
|
|
|
|
static __always_inline bool __cpus_have_const_cap(int num)
|
|
|
|
{
|
|
|
|
if (num >= ARM64_NCAPS)
|
|
|
|
return false;
|
|
|
|
return static_branch_unlikely(&cpu_hwcap_keys[num]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Test for a capability, possibly with a runtime check.
|
|
|
|
*
|
|
|
|
* Before capabilities are finalized, this behaves as cpus_have_cap().
|
|
|
|
* After capabilities are finalized, this is patched to avoid a runtime check.
|
|
|
|
*
|
|
|
|
* @num must be a compile-time constant.
|
|
|
|
*/
|
2019-05-14 22:41:52 +00:00
|
|
|
static __always_inline bool cpus_have_const_cap(int num)
|
arm64/cpufeature: don't use mutex in bringup path
Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which
must take the jump_label mutex.
We call cpus_set_cap() in the secondary bringup path, from the idle
thread where interrupts are disabled. Taking a mutex in this path "is a
NONO" regardless of whether it's contended, and something we must avoid.
We didn't spot this until recently, as ___might_sleep() won't warn for
this case until all CPUs have been brought up.
This patch avoids taking the mutex in the secondary bringup path. The
poking of static keys is deferred until enable_cpu_capabilities(), which
runs in a suitable context on the boot CPU. To account for the static
keys being set later, cpus_have_const_cap() is updated to use another
static key to check whether the const cap keys have been initialised,
falling back to the caps bitmap until this is the case.
This means that users of cpus_have_const_cap() gain should only gain a
single additional NOP in the fast path once the const caps are
initialised, but should always see the current cap value.
The hyp code should never dereference the caps array, since the caps are
initialized before we run the module initcall to initialise hyp. A check
is added to the hyp init code to document this requirement.
This change will sidestep a number of issues when the upcoming hotplug
locking rework is merged.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyniger <marc.zyngier@arm.com>
Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-16 14:18:05 +00:00
|
|
|
{
|
arm64: cpufeature: add cpus_have_final_cap()
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
We then made use of cpus_have_const_cap() throughout the kernel.
Subsequently, we had to defer updating the static_key associated with
each capability in order to avoid lockdep complaints. To avoid breaking
kernel-wide usage of cpus_have_const_cap(), this was updated to fall
back to the cpu_hwcaps array if called before the static_keys were
updated. As the kvm hyp code was only called later than this, the
fallback is redundant but not functionally harmful. For more details,
see commit:
63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
Today we have more users of cpus_have_const_cap() which are only called
once the relevant static keys are initialized, and it would be
beneficial to avoid the redundant code.
To that end, this patch adds a new cpus_have_final_cap(), helper which
is intend to be used in code which is only run once capabilities have
been finalized, and will never check the cpus_hwcap array. This helps
the compiler to generate better code as it no longer needs to generate
code to address and test the cpus_hwcap array. To help catch misuse,
cpus_have_final_cap() will BUG() if called before capabilities are
finalized.
In hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers. Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-02-21 14:50:21 +00:00
|
|
|
if (system_capabilities_finalized())
|
arm64/cpufeature: don't use mutex in bringup path
Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which
must take the jump_label mutex.
We call cpus_set_cap() in the secondary bringup path, from the idle
thread where interrupts are disabled. Taking a mutex in this path "is a
NONO" regardless of whether it's contended, and something we must avoid.
We didn't spot this until recently, as ___might_sleep() won't warn for
this case until all CPUs have been brought up.
This patch avoids taking the mutex in the secondary bringup path. The
poking of static keys is deferred until enable_cpu_capabilities(), which
runs in a suitable context on the boot CPU. To account for the static
keys being set later, cpus_have_const_cap() is updated to use another
static key to check whether the const cap keys have been initialised,
falling back to the caps bitmap until this is the case.
This means that users of cpus_have_const_cap() gain should only gain a
single additional NOP in the fast path once the const caps are
initialised, but should always see the current cap value.
The hyp code should never dereference the caps array, since the caps are
initialized before we run the module initcall to initialise hyp. A check
is added to the hyp init code to document this requirement.
This change will sidestep a number of issues when the upcoming hotplug
locking rework is merged.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyniger <marc.zyngier@arm.com>
Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-16 14:18:05 +00:00
|
|
|
return __cpus_have_const_cap(num);
|
|
|
|
else
|
|
|
|
return cpus_have_cap(num);
|
|
|
|
}
|
|
|
|
|
arm64: cpufeature: add cpus_have_final_cap()
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
We then made use of cpus_have_const_cap() throughout the kernel.
Subsequently, we had to defer updating the static_key associated with
each capability in order to avoid lockdep complaints. To avoid breaking
kernel-wide usage of cpus_have_const_cap(), this was updated to fall
back to the cpu_hwcaps array if called before the static_keys were
updated. As the kvm hyp code was only called later than this, the
fallback is redundant but not functionally harmful. For more details,
see commit:
63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
Today we have more users of cpus_have_const_cap() which are only called
once the relevant static keys are initialized, and it would be
beneficial to avoid the redundant code.
To that end, this patch adds a new cpus_have_final_cap(), helper which
is intend to be used in code which is only run once capabilities have
been finalized, and will never check the cpus_hwcap array. This helps
the compiler to generate better code as it no longer needs to generate
code to address and test the cpus_hwcap array. To help catch misuse,
cpus_have_final_cap() will BUG() if called before capabilities are
finalized.
In hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers. Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-02-21 14:50:21 +00:00
|
|
|
/*
|
|
|
|
* Test for a capability without a runtime check.
|
|
|
|
*
|
|
|
|
* Before capabilities are finalized, this will BUG().
|
|
|
|
* After capabilities are finalized, this is patched to avoid a runtime check.
|
|
|
|
*
|
|
|
|
* @num must be a compile-time constant.
|
|
|
|
*/
|
|
|
|
static __always_inline bool cpus_have_final_cap(int num)
|
|
|
|
{
|
|
|
|
if (system_capabilities_finalized())
|
|
|
|
return __cpus_have_const_cap(num);
|
|
|
|
else
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
2014-11-14 15:54:07 +00:00
|
|
|
static inline void cpus_set_cap(unsigned int num)
|
|
|
|
{
|
2016-09-05 17:25:48 +00:00
|
|
|
if (num >= ARM64_NCAPS) {
|
2014-11-14 15:54:07 +00:00
|
|
|
pr_warn("Attempt to set an illegal CPU capability (%d >= %d)\n",
|
arm64: Provide a namespace to NCAPS
Building arm64.allmodconfig leads to the following warning:
usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined
#define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
^
In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0,
from /home/build/work/batch/include/linux/clocksource.h:19,
from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19,
from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27,
from /home/build/work/batch/arch/arm64/include/asm/timex.h:19,
from /home/build/work/batch/include/linux/timex.h:65,
from /home/build/work/batch/include/linux/sched.h:19,
from /home/build/work/batch/arch/arm64/include/asm/compat.h:25,
from /home/build/work/batch/arch/arm64/include/asm/stat.h:23,
from /home/build/work/batch/include/linux/stat.h:5,
from /home/build/work/batch/include/linux/module.h:10,
from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19:
arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition
#define NCAPS 2
So add a ARM64 prefix to avoid such problem.
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-04 01:17:01 +00:00
|
|
|
num, ARM64_NCAPS);
|
2016-09-05 17:25:48 +00:00
|
|
|
} else {
|
2014-11-14 15:54:07 +00:00
|
|
|
__set_bit(num, cpu_hwcaps);
|
2016-09-05 17:25:48 +00:00
|
|
|
}
|
2014-11-14 15:54:07 +00:00
|
|
|
}
|
|
|
|
|
2015-10-19 13:24:44 +00:00
|
|
|
static inline int __attribute_const__
|
2016-01-26 10:58:16 +00:00
|
|
|
cpuid_feature_extract_signed_field_width(u64 features, int field, int width)
|
2015-07-21 12:23:26 +00:00
|
|
|
{
|
2015-10-19 13:24:44 +00:00
|
|
|
return (s64)(features << (64 - width - field)) >> (64 - width);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int __attribute_const__
|
2016-01-26 10:58:16 +00:00
|
|
|
cpuid_feature_extract_signed_field(u64 features, int field)
|
2015-10-19 13:24:44 +00:00
|
|
|
{
|
2016-01-26 10:58:16 +00:00
|
|
|
return cpuid_feature_extract_signed_field_width(features, field, 4);
|
2015-07-21 12:23:26 +00:00
|
|
|
}
|
|
|
|
|
2020-02-20 16:58:39 +00:00
|
|
|
static __always_inline unsigned int __attribute_const__
|
2015-11-18 17:08:56 +00:00
|
|
|
cpuid_feature_extract_unsigned_field_width(u64 features, int field, int width)
|
|
|
|
{
|
|
|
|
return (u64)(features << (64 - width - field)) >> (64 - width);
|
|
|
|
}
|
|
|
|
|
2020-02-20 16:58:39 +00:00
|
|
|
static __always_inline unsigned int __attribute_const__
|
2015-11-18 17:08:56 +00:00
|
|
|
cpuid_feature_extract_unsigned_field(u64 features, int field)
|
|
|
|
{
|
|
|
|
return cpuid_feature_extract_unsigned_field_width(features, field, 4);
|
|
|
|
}
|
|
|
|
|
2020-03-02 18:17:50 +00:00
|
|
|
/*
|
|
|
|
* Fields that identify the version of the Performance Monitors Extension do
|
|
|
|
* not follow the standard ID scheme. See ARM DDI 0487E.a page D13-2825,
|
|
|
|
* "Alternative ID scheme used for the Performance Monitors Extension version".
|
|
|
|
*/
|
|
|
|
static inline u64 __attribute_const__
|
|
|
|
cpuid_feature_cap_perfmon_field(u64 features, int field, u64 cap)
|
|
|
|
{
|
|
|
|
u64 val = cpuid_feature_extract_unsigned_field(features, field);
|
|
|
|
u64 mask = GENMASK_ULL(field + 3, field);
|
|
|
|
|
|
|
|
/* Treat IMPLEMENTATION DEFINED functionality as unimplemented */
|
|
|
|
if (val == 0xf)
|
|
|
|
val = 0;
|
|
|
|
|
|
|
|
if (val > cap) {
|
|
|
|
features &= ~mask;
|
|
|
|
features |= (cap << field) & mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
return features;
|
|
|
|
}
|
|
|
|
|
2016-08-31 10:31:08 +00:00
|
|
|
static inline u64 arm64_ftr_mask(const struct arm64_ftr_bits *ftrp)
|
2015-10-19 13:24:45 +00:00
|
|
|
{
|
|
|
|
return (u64)GENMASK(ftrp->shift + ftrp->width - 1, ftrp->shift);
|
|
|
|
}
|
|
|
|
|
2017-01-09 17:28:30 +00:00
|
|
|
static inline u64 arm64_ftr_reg_user_value(const struct arm64_ftr_reg *reg)
|
|
|
|
{
|
|
|
|
return (reg->user_val | (reg->sys_val & reg->user_mask));
|
|
|
|
}
|
|
|
|
|
2016-01-26 10:58:16 +00:00
|
|
|
static inline int __attribute_const__
|
arm64/cpufeature: check correct field width when updating sys_val
When we're updating a register's sys_val, we use arm64_ftr_value() to
find the new field value. We use cpuid_feature_extract_field() to find
the new value, but this implicitly assumes a 4-bit field, so we may
extract more bits than we mean to for fields like CTR_EL0.L1ip.
This affects update_cpu_ftr_reg(), where we may extract erroneous values
for ftr_cur and ftr_new. Depending on the additional bits extracted in
either case, we may erroneously detect that the value is mismatched, and
we'll try to compute a new safe value.
Dependent on these extra bits and feature type, arm64_ftr_safe_value()
may pessimistically select the always-safe value, or may erroneously
choose either the extracted cur or new value as the safe option. The
extra bits will subsequently be masked out in arm64_ftr_set_value(), so
we may choose a higher value, yet write back a lower one.
Fix this by passing the width down explicitly in arm64_ftr_value(), so
we always extract the correct amount.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-02-23 16:03:17 +00:00
|
|
|
cpuid_feature_extract_field_width(u64 features, int field, int width, bool sign)
|
2016-01-26 10:58:16 +00:00
|
|
|
{
|
|
|
|
return (sign) ?
|
arm64/cpufeature: check correct field width when updating sys_val
When we're updating a register's sys_val, we use arm64_ftr_value() to
find the new field value. We use cpuid_feature_extract_field() to find
the new value, but this implicitly assumes a 4-bit field, so we may
extract more bits than we mean to for fields like CTR_EL0.L1ip.
This affects update_cpu_ftr_reg(), where we may extract erroneous values
for ftr_cur and ftr_new. Depending on the additional bits extracted in
either case, we may erroneously detect that the value is mismatched, and
we'll try to compute a new safe value.
Dependent on these extra bits and feature type, arm64_ftr_safe_value()
may pessimistically select the always-safe value, or may erroneously
choose either the extracted cur or new value as the safe option. The
extra bits will subsequently be masked out in arm64_ftr_set_value(), so
we may choose a higher value, yet write back a lower one.
Fix this by passing the width down explicitly in arm64_ftr_value(), so
we always extract the correct amount.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-02-23 16:03:17 +00:00
|
|
|
cpuid_feature_extract_signed_field_width(features, field, width) :
|
|
|
|
cpuid_feature_extract_unsigned_field_width(features, field, width);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int __attribute_const__
|
|
|
|
cpuid_feature_extract_field(u64 features, int field, bool sign)
|
|
|
|
{
|
|
|
|
return cpuid_feature_extract_field_width(features, field, 4, sign);
|
2016-01-26 10:58:16 +00:00
|
|
|
}
|
|
|
|
|
2016-08-31 10:31:08 +00:00
|
|
|
static inline s64 arm64_ftr_value(const struct arm64_ftr_bits *ftrp, u64 val)
|
2015-10-19 13:24:45 +00:00
|
|
|
{
|
arm64/cpufeature: check correct field width when updating sys_val
When we're updating a register's sys_val, we use arm64_ftr_value() to
find the new field value. We use cpuid_feature_extract_field() to find
the new value, but this implicitly assumes a 4-bit field, so we may
extract more bits than we mean to for fields like CTR_EL0.L1ip.
This affects update_cpu_ftr_reg(), where we may extract erroneous values
for ftr_cur and ftr_new. Depending on the additional bits extracted in
either case, we may erroneously detect that the value is mismatched, and
we'll try to compute a new safe value.
Dependent on these extra bits and feature type, arm64_ftr_safe_value()
may pessimistically select the always-safe value, or may erroneously
choose either the extracted cur or new value as the safe option. The
extra bits will subsequently be masked out in arm64_ftr_set_value(), so
we may choose a higher value, yet write back a lower one.
Fix this by passing the width down explicitly in arm64_ftr_value(), so
we always extract the correct amount.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-02-23 16:03:17 +00:00
|
|
|
return (s64)cpuid_feature_extract_field_width(val, ftrp->shift, ftrp->width, ftrp->sign);
|
2015-10-19 13:24:45 +00:00
|
|
|
}
|
|
|
|
|
2015-10-19 13:24:42 +00:00
|
|
|
static inline bool id_aa64mmfr0_mixed_endian_el0(u64 mmfr0)
|
2015-07-21 12:23:26 +00:00
|
|
|
{
|
2016-01-26 10:58:16 +00:00
|
|
|
return cpuid_feature_extract_unsigned_field(mmfr0, ID_AA64MMFR0_BIGENDEL_SHIFT) == 0x1 ||
|
|
|
|
cpuid_feature_extract_unsigned_field(mmfr0, ID_AA64MMFR0_BIGENDEL0_SHIFT) == 0x1;
|
2015-07-21 12:23:26 +00:00
|
|
|
}
|
|
|
|
|
2020-04-21 14:29:20 +00:00
|
|
|
static inline bool id_aa64pfr0_32bit_el1(u64 pfr0)
|
|
|
|
{
|
|
|
|
u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL1_SHIFT);
|
|
|
|
|
|
|
|
return val == ID_AA64PFR0_EL1_32BIT_64BIT;
|
|
|
|
}
|
|
|
|
|
2016-04-18 09:28:34 +00:00
|
|
|
static inline bool id_aa64pfr0_32bit_el0(u64 pfr0)
|
|
|
|
{
|
|
|
|
u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL0_SHIFT);
|
|
|
|
|
|
|
|
return val == ID_AA64PFR0_EL0_32BIT_64BIT;
|
|
|
|
}
|
|
|
|
|
2017-10-31 15:51:10 +00:00
|
|
|
static inline bool id_aa64pfr0_sve(u64 pfr0)
|
|
|
|
{
|
|
|
|
u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_SVE_SHIFT);
|
|
|
|
|
|
|
|
return val > 0;
|
|
|
|
}
|
|
|
|
|
2015-10-19 13:24:39 +00:00
|
|
|
void __init setup_cpu_features(void);
|
2016-09-09 13:07:10 +00:00
|
|
|
void check_local_cpu_capabilities(void);
|
|
|
|
|
2017-03-23 15:14:39 +00:00
|
|
|
u64 read_sanitised_ftr_reg(u32 id);
|
2015-10-19 13:24:47 +00:00
|
|
|
|
2015-10-19 13:24:48 +00:00
|
|
|
static inline bool cpu_supports_mixed_endian_el0(void)
|
|
|
|
{
|
|
|
|
return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
|
|
|
|
}
|
|
|
|
|
2016-04-18 09:28:36 +00:00
|
|
|
static inline bool system_supports_32bit_el0(void)
|
|
|
|
{
|
2016-11-08 13:56:20 +00:00
|
|
|
return cpus_have_const_cap(ARM64_HAS_32BIT_EL0);
|
2016-04-18 09:28:36 +00:00
|
|
|
}
|
|
|
|
|
2018-11-15 05:52:47 +00:00
|
|
|
static inline bool system_supports_4kb_granule(void)
|
|
|
|
{
|
|
|
|
u64 mmfr0;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
|
|
|
|
val = cpuid_feature_extract_unsigned_field(mmfr0,
|
|
|
|
ID_AA64MMFR0_TGRAN4_SHIFT);
|
|
|
|
|
|
|
|
return val == ID_AA64MMFR0_TGRAN4_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool system_supports_64kb_granule(void)
|
|
|
|
{
|
|
|
|
u64 mmfr0;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
|
|
|
|
val = cpuid_feature_extract_unsigned_field(mmfr0,
|
|
|
|
ID_AA64MMFR0_TGRAN64_SHIFT);
|
|
|
|
|
|
|
|
return val == ID_AA64MMFR0_TGRAN64_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool system_supports_16kb_granule(void)
|
|
|
|
{
|
|
|
|
u64 mmfr0;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
|
|
|
|
val = cpuid_feature_extract_unsigned_field(mmfr0,
|
|
|
|
ID_AA64MMFR0_TGRAN16_SHIFT);
|
|
|
|
|
|
|
|
return val == ID_AA64MMFR0_TGRAN16_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
2015-10-19 13:24:48 +00:00
|
|
|
static inline bool system_supports_mixed_endian_el0(void)
|
|
|
|
{
|
2017-03-23 15:14:39 +00:00
|
|
|
return id_aa64mmfr0_mixed_endian_el0(read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1));
|
2015-10-19 13:24:48 +00:00
|
|
|
}
|
2014-11-14 15:54:09 +00:00
|
|
|
|
2018-11-15 05:52:47 +00:00
|
|
|
static inline bool system_supports_mixed_endian(void)
|
|
|
|
{
|
|
|
|
u64 mmfr0;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
|
|
|
|
val = cpuid_feature_extract_unsigned_field(mmfr0,
|
|
|
|
ID_AA64MMFR0_BIGENDEL_SHIFT);
|
|
|
|
|
|
|
|
return val == 0x1;
|
|
|
|
}
|
|
|
|
|
2020-02-20 16:58:39 +00:00
|
|
|
static __always_inline bool system_supports_fpsimd(void)
|
2016-11-08 13:56:21 +00:00
|
|
|
{
|
|
|
|
return !cpus_have_const_cap(ARM64_HAS_NO_FPSIMD);
|
|
|
|
}
|
|
|
|
|
2016-07-01 15:53:00 +00:00
|
|
|
static inline bool system_uses_ttbr0_pan(void)
|
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_SW_TTBR0_PAN) &&
|
arm64: use const cap for system_uses_ttbr0_pan()
Since commit 4b65a5db362783ab ("arm64: Introduce
uaccess_{disable,enable} functionality based on TTBR0_EL1"),
system_uses_ttbr0_pan() has used cpus_have_cap() to determine whether
PAN is present.
Since commit a4023f682739439b ("arm64: Add hypervisor safe helper for
checking constant capabilities"), which was introduced around the same
time, cpus_have_cap() doesn't try to use a static key, and must always
perform a load, test, and consitional branch (likely a tbnz for the
latter two).
Elsewhere, we moved to using cpus_have_const_cap(), which can use a
static key (i.e. a non-conditional branch), which is patched at runtime
when the feature is detected.
This patch makes system_uses_ttbr0_pan() use cpus_have_const_cap(). The
static key is likely a win for hot-paths like the uacccess primitives,
and this makes our usage consistent regardless.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-03-10 17:44:18 +00:00
|
|
|
!cpus_have_const_cap(ARM64_HAS_PAN);
|
2016-07-01 15:53:00 +00:00
|
|
|
}
|
|
|
|
|
2020-02-20 16:58:39 +00:00
|
|
|
static __always_inline bool system_supports_sve(void)
|
2017-10-31 15:51:02 +00:00
|
|
|
{
|
2017-10-31 15:51:19 +00:00
|
|
|
return IS_ENABLED(CONFIG_ARM64_SVE) &&
|
|
|
|
cpus_have_const_cap(ARM64_SVE);
|
2017-10-31 15:51:02 +00:00
|
|
|
}
|
|
|
|
|
2020-02-20 16:58:37 +00:00
|
|
|
static __always_inline bool system_supports_cnp(void)
|
2018-07-31 13:08:56 +00:00
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_CNP) &&
|
|
|
|
cpus_have_const_cap(ARM64_HAS_CNP);
|
|
|
|
}
|
|
|
|
|
2018-12-07 18:39:24 +00:00
|
|
|
static inline bool system_supports_address_auth(void)
|
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_PTR_AUTH) &&
|
2020-03-13 09:04:49 +00:00
|
|
|
cpus_have_const_cap(ARM64_HAS_ADDRESS_AUTH);
|
2018-12-07 18:39:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool system_supports_generic_auth(void)
|
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_PTR_AUTH) &&
|
2020-03-13 09:04:49 +00:00
|
|
|
cpus_have_const_cap(ARM64_HAS_GENERIC_AUTH);
|
2018-12-07 18:39:24 +00:00
|
|
|
}
|
|
|
|
|
2020-06-18 17:12:54 +00:00
|
|
|
static __always_inline bool system_uses_irq_prio_masking(void)
|
2019-01-31 14:58:42 +00:00
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) &&
|
|
|
|
cpus_have_const_cap(ARM64_HAS_IRQ_PRIO_MASKING);
|
|
|
|
}
|
|
|
|
|
2019-06-11 09:38:11 +00:00
|
|
|
static inline bool system_has_prio_mask_debugging(void)
|
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING) &&
|
|
|
|
system_uses_irq_prio_masking();
|
|
|
|
}
|
|
|
|
|
2020-03-16 16:50:45 +00:00
|
|
|
static inline bool system_supports_bti(void)
|
|
|
|
{
|
2020-05-05 14:15:58 +00:00
|
|
|
return IS_ENABLED(CONFIG_ARM64_BTI) && cpus_have_const_cap(ARM64_BTI);
|
2020-01-13 23:30:17 +00:00
|
|
|
}
|
|
|
|
|
arm64: tlb: Use the TLBI RANGE feature in arm64
Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range().
When cpu supports TLBI feature, the minimum range granularity is
decided by 'scale', so we can not flush all pages by one instruction
in some cases.
For example, when the pages = 0xe81a, let's start 'scale' from
maximum, and find right 'num' for each 'scale':
1. scale = 3, we can flush no pages because the minimum range is
2^(5*3 + 1) = 0x10000.
2. scale = 2, the minimum range is 2^(5*2 + 1) = 0x800, we can
flush 0xe800 pages this time, the num = 0xe800/0x800 - 1 = 0x1c.
Remaining pages is 0x1a;
3. scale = 1, the minimum range is 2^(5*1 + 1) = 0x40, no page
can be flushed.
4. scale = 0, we flush the remaining 0x1a pages, the num =
0x1a/0x2 - 1 = 0xd.
However, in most scenarios, the pages = 1 when flush_tlb_range() is
called. Start from scale = 3 or other proper value (such as scale =
ilog2(pages)), will incur extra overhead.
So increase 'scale' from 0 to maximum, the flush order is exactly
opposite to the example.
Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com>
Link: https://lore.kernel.org/r/20200715071945.897-4-yezhenyu2@huawei.com
[catalin.marinas@arm.com: removed unnecessary masks in __TLBI_VADDR_RANGE]
[catalin.marinas@arm.com: __TLB_RANGE_NUM subtracts 1]
[catalin.marinas@arm.com: minor adjustments to the comments]
[catalin.marinas@arm.com: introduce system_supports_tlb_range()]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-07-15 07:19:45 +00:00
|
|
|
static inline bool system_supports_tlb_range(void)
|
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_ARM64_TLB_RANGE) &&
|
|
|
|
cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
|
|
|
|
}
|
|
|
|
|
2019-05-03 14:27:48 +00:00
|
|
|
#define ARM64_BP_HARDEN_UNKNOWN -1
|
|
|
|
#define ARM64_BP_HARDEN_WA_NEEDED 0
|
|
|
|
#define ARM64_BP_HARDEN_NOT_REQUIRED 1
|
|
|
|
|
|
|
|
int get_spectre_v2_workaround_state(void);
|
|
|
|
|
2018-05-29 12:11:09 +00:00
|
|
|
#define ARM64_SSBD_UNKNOWN -1
|
|
|
|
#define ARM64_SSBD_FORCE_DISABLE 0
|
|
|
|
#define ARM64_SSBD_KERNEL 1
|
|
|
|
#define ARM64_SSBD_FORCE_ENABLE 2
|
|
|
|
#define ARM64_SSBD_MITIGATED 3
|
|
|
|
|
2018-05-29 12:11:10 +00:00
|
|
|
static inline int arm64_get_ssbd_state(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_ARM64_SSBD
|
|
|
|
extern int ssbd_state;
|
|
|
|
return ssbd_state;
|
|
|
|
#else
|
|
|
|
return ARM64_SSBD_UNKNOWN;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2018-05-29 12:11:12 +00:00
|
|
|
void arm64_set_ssbd_mitigation(bool state);
|
|
|
|
|
2018-09-20 04:06:20 +00:00
|
|
|
extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
|
2018-10-26 00:57:35 +00:00
|
|
|
|
2018-09-26 16:32:40 +00:00
|
|
|
static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
|
|
|
|
{
|
|
|
|
switch (parange) {
|
|
|
|
case 0: return 32;
|
|
|
|
case 1: return 36;
|
|
|
|
case 2: return 40;
|
|
|
|
case 3: return 42;
|
|
|
|
case 4: return 44;
|
|
|
|
case 5: return 48;
|
|
|
|
case 6: return 52;
|
|
|
|
/*
|
|
|
|
* A future PE could use a value unknown to the kernel.
|
|
|
|
* However, by the "D10.1.4 Principles of the ID scheme
|
|
|
|
* for fields in ID registers", ARM DDI 0487C.a, any new
|
|
|
|
* value is guaranteed to be higher than what we know already.
|
|
|
|
* As a safe limit, we return the limit supported by the kernel.
|
|
|
|
*/
|
|
|
|
default: return CONFIG_ARM64_PA_BITS;
|
|
|
|
}
|
|
|
|
}
|
2019-10-11 14:09:36 +00:00
|
|
|
|
|
|
|
/* Check whether hardware update of the Access flag is supported */
|
|
|
|
static inline bool cpu_has_hw_af(void)
|
|
|
|
{
|
|
|
|
u64 mmfr1;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
mmfr1 = read_cpuid(ID_AA64MMFR1_EL1);
|
|
|
|
return cpuid_feature_extract_unsigned_field(mmfr1,
|
|
|
|
ID_AA64MMFR1_HADBS_SHIFT);
|
|
|
|
}
|
|
|
|
|
2020-03-05 09:06:21 +00:00
|
|
|
#ifdef CONFIG_ARM64_AMU_EXTN
|
|
|
|
/* Check whether the cpu supports the Activity Monitors Unit (AMU) */
|
|
|
|
extern bool cpu_has_amu_feat(int cpu);
|
|
|
|
#endif
|
|
|
|
|
2020-05-12 01:57:27 +00:00
|
|
|
static inline unsigned int get_vmid_bits(u64 mmfr1)
|
|
|
|
{
|
|
|
|
int vmid_bits;
|
|
|
|
|
|
|
|
vmid_bits = cpuid_feature_extract_unsigned_field(mmfr1,
|
|
|
|
ID_AA64MMFR1_VMIDBITS_SHIFT);
|
|
|
|
if (vmid_bits == ID_AA64MMFR1_VMIDBITS_16)
|
|
|
|
return 16;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the default here even if any reserved
|
|
|
|
* value is fetched from the system register.
|
|
|
|
*/
|
|
|
|
return 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
u32 get_kvm_ipa_limit(void);
|
2020-06-29 04:38:31 +00:00
|
|
|
void dump_cpu_features(void);
|
2020-05-12 01:57:27 +00:00
|
|
|
|
2014-11-14 15:54:10 +00:00
|
|
|
#endif /* __ASSEMBLY__ */
|
|
|
|
|
2014-03-04 01:10:04 +00:00
|
|
|
#endif
|