github
/
arm-trusted-firmware
mirror of https://github.com/ARM-software/arm-trusted-firmware.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
14066 Commits
5 Branches
114 Tags
55 MiB
Tree: b06317fab2
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b06317fab2'
${ noResults }
arm-trusted-firmware/common/feat_detect.c

231 lines
8.8 KiB
Raw Normal View History

refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro "FEATURE_DETECTION", which is currently being disabled by default. The "FEATURE_DETECTION" macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this "FEATURE_DETECTION" flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/*
refactor(mte): deprecate CTX_INCLUDE_MTE_REGS Currently CTX_INCLUDE_MTE_REGS is used for dual purpose, to enable allocation tags register and to context save and restore them and also to check if mte feature is available. To make it more meaningful, remove CTX_INCLUDE_MTE_REGS and introduce FEAT_MTE. This would enable allocation tags register when FEAT_MTE is enabled and also supported from platform. Also arch features can be conditionally enabled disabled based on arch version from `make_helpers/arch_features.mk` Change-Id: Ibdd2d43874634ad7ddff93c7edad6044ae1631ed Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
11 months ago
* Copyright (c) 2022-2024, Arm Limited and Contributors. All rights reserved.
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro "FEATURE_DETECTION", which is currently being disabled by default. The "FEATURE_DETECTION" macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this "FEATURE_DETECTION" flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
*
* SPDX-License-Identifier: BSD-3-Clause
*/
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the "0" case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes "static inline", since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category "cpufeat" to cover CPU feature related changes. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
#include <arch_features.h>
#include <common/debug.h>
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
#include <common/feat_detect.h>
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
static bool tainted;
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/*******************************************************************************
* This section lists the wrapper modules for each feature to evaluate the
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
* feature states (FEAT_STATE_ALWAYS and FEAT_STATE_CHECK) and perform
* necessary action as below:
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
*
* It verifies whether the FEAT_XXX (eg: FEAT_SB) is supported by the PE or not.
* Without this check an exception would occur during context save/restore
* routines, if the feature is enabled but not supported by PE.
******************************************************************************/
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
#define feat_detect_panic(a, b) ((a) ? (void)0 : feature_panic(b))
/*******************************************************************************
* Function : feature_panic
* Customised panic function with error logging mechanism to list the feature
* not supported by the PE.
******************************************************************************/
static inline void feature_panic(char *feat_name)
{
ERROR("FEAT_%s not supported by the PE\n", feat_name);
panic();
}
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
/*******************************************************************************
* Function : check_feature
* Check for a valid combination of build time flags (ENABLE_FEAT_xxx) and
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
* feature availability on the hardware. <min> is the smallest feature
* ID field value that is required for that feature.
* Triggers a panic later if a feature is forcefully enabled, but not
* available on the PE. Also will panic if the hardware feature ID field
* is larger than the maximum known and supported number, specified by <max>.
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
*
* We force inlining here to let the compiler optimise away the whole check
* if the feature is disabled at build time (FEAT_STATE_DISABLED).
******************************************************************************/
static inline void __attribute((__always_inline__))
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(int state, unsigned long field, const char *feat_name,
unsigned int min, unsigned int max)
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
{
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
if (state == FEAT_STATE_ALWAYS && field < min) {
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
ERROR("FEAT_%s not supported by the PE\n", feat_name);
tainted = true;
}
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
if (state >= FEAT_STATE_ALWAYS && field > max) {
ERROR("FEAT_%s is version %ld, but is only known up to version %d\n",
feat_name, field, max);
tainted = true;
}
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
}
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/************************************************
* Feature : FEAT_PAUTH (Pointer Authentication)
***********************************************/
static void read_feat_pauth(void)
{
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
#if (ENABLE_PAUTH == FEAT_STATE_ALWAYS) || (CTX_INCLUDE_PAUTH_REGS == FEAT_STATE_ALWAYS)
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
feat_detect_panic(is_armv8_3_pauth_present(), "PAUTH");
#endif
}
/****************************************************
* Feature : FEAT_BTI (Branch Target Identification)
***************************************************/
static void read_feat_bti(void)
{
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
#if (ENABLE_BTI == FEAT_STATE_ALWAYS)
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
feat_detect_panic(is_armv8_5_bti_present(), "BTI");
#endif
}
/**************************************************
* Feature : FEAT_RME (Realm Management Extension)
*************************************************/
static void read_feat_rme(void)
{
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
#if (ENABLE_RME == FEAT_STATE_ALWAYS)
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
feat_detect_panic((get_armv9_2_feat_rme_support() !=
ID_AA64PFR0_FEAT_RME_NOT_SUPPORTED), "RME");
#endif
}
feat(rng-trap): add EL3 support for FEAT_RNG_TRAP FEAT_RNG_TRAP introduces support for EL3 trapping of reads of the RNDR and RNDRRS registers, which is enabled by setting the SCR_EL3.TRNDR bit. This patch adds a new build flag ENABLE_FEAT_RNG_TRAP that enables the feature. This feature is supported only in AArch64 state from Armv8.5 onwards. Signed-off-by: Juan Pablo Conde &lt;juanpablo.conde@arm.com&gt; Change-Id: Ia9f17aef3444d3822bf03809036a1f668c9f2d89
2 years ago
/******************************************************************
* Feature : FEAT_RNG_TRAP (Trapping support for RNDR/RNDRRS)
*****************************************************************/
static void read_feat_rng_trap(void)
{
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
#if (ENABLE_FEAT_RNG_TRAP == FEAT_STATE_ALWAYS)
feat(rng-trap): add EL3 support for FEAT_RNG_TRAP FEAT_RNG_TRAP introduces support for EL3 trapping of reads of the RNDR and RNDRRS registers, which is enabled by setting the SCR_EL3.TRNDR bit. This patch adds a new build flag ENABLE_FEAT_RNG_TRAP that enables the feature. This feature is supported only in AArch64 state from Armv8.5 onwards. Signed-off-by: Juan Pablo Conde &lt;juanpablo.conde@arm.com&gt; Change-Id: Ia9f17aef3444d3822bf03809036a1f668c9f2d89
2 years ago
feat_detect_panic(is_feat_rng_trap_present(), "RNG_TRAP");
#endif
}
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/***********************************************************************************
* TF-A supports many Arm architectural features starting from arch version
* (8.0 till 8.7+). These features are mostly enabled through build flags. This
* mechanism helps in validating these build flags in the early boot phase
* either in BL1 or BL31 depending on the platform and assists in identifying
* and notifying the features which are enabled but not supported by the PE.
*
* It reads all the enabled features ID-registers and ensures the features
* are supported by the PE.
* In case if they aren't it stops booting at an early phase and logs the error
* messages, notifying the platforms about the features that are not supported.
*
* Further the procedure is implemented with a tri-state approach for each feature:
* ENABLE_FEAT_xxx = 0 : The feature is disabled statically at compile time
* ENABLE_FEAT_xxx = 1 : The feature is enabled and must be present in hardware.
* There will be panic if feature is not present at cold boot.
* ENABLE_FEAT_xxx = 2 : The feature is enabled but dynamically enabled at runtime
* depending on hardware capability.
*
refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the &#34;0&#34; case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes &#34;static inline&#34;, since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category &#34;cpufeat&#34; to cover CPU feature related changes. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc
2 years ago
* For better readability, state values are defined with macros, namely:
* { FEAT_STATE_DISABLED, FEAT_STATE_ALWAYS, FEAT_STATE_CHECK }, taking values
* { 0, 1, 2 }, respectively, as their naming.
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
**********************************************************************************/
void detect_arch_features(void)
{
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
tainted = false;
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.0 features */
refactor(cpufeat): align FEAT_SB to new feature handling FEAT_SB introduces a new speculation barrier instruction, that is more lightweight than a &#34;dsb; isb&#34; combination. We use that in a hot path, so cannot afford and don&#39;t want a runtime detection mechanism. Nevertheless align the implementation of the feature detection part with the other features, but renaming the detection function, and updating the FEAT_DETECTION code. Also update the documentation. Change-Id: I2b86dfd1ad259c3bb99ab5186e2911ace454b54c Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_SB, read_feat_sb_id_field(), "SB", 1, 1);
refactor(cpufeat): enable FEAT_CSV2_2 for FEAT_STATE_CHECKED At the moment we only support FEAT_CSV2_2 to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_FEAT_CSV2_2=2), by splitting is_armv8_0_feat_csv2_2_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access the SCXTNUM_EL2 system register. Also move the context saving code from assembly to C, and use the new is_feat_csv2_2_supported() function to guard its execution. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I89c7bc883e6a65727fdbdd36eb3bfbffb2196da7 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_CSV2_2, read_feat_csv2_id_field(),
"CSV2_2", 2, 3);
feat(pmu): introduce pmuv3 lib/extensions folder The enablement code for the PMU is scattered and difficult to track down. Factor out the feature into its own lib/extensions folder and consolidate the implementation. Treat it is as an architecturally mandatory feature as it is currently. Additionally, do some cleanup on AArch64. Setting overflow bits in PMCR_EL0 is irrelevant for firmware so don&#39;t do it. Then delay the PMU initialisation until the context management stage which simplifies the early environment assembly. One side effect is that the PMU might count before this happens so reset all counters to 0 to prevent any leakage. Finally, add an enable to manage_extensions_realm() as realm world uses the pmu. This introduces the HPMN fixup to realm world. Signed-off-by: Boyan Karatotev &lt;boyan.karatotev@arm.com&gt; Change-Id: Ie13a8625820ecc5fbfa467dc6ca18025bf6a9cd3
2 years ago
/*
* Even though the PMUv3 is an OPTIONAL feature, it is always
* implemented and Arm prescribes so. So assume it will be there and do
* away with a flag for it. This is used to check minor PMUv3px
* revisions so that we catch them as they come along
*/
check_feature(FEAT_STATE_ALWAYS, read_feat_pmuv3_id_field(),
"PMUv3", 1, ID_AA64DFR0_PMUVER_PMUV3P7);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.1 features */
refactor(cpufeat): enable FEAT_PAN for FEAT_STATE_CHECKED At the moment we only support FEAT_PAN to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_FEAT_PAN=2), by splitting is_armv8_1_pan_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we PAN specific setup. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I58e5fe8d3c9332820391c7d93a8fb9dba4cf754a Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_PAN, read_feat_pan_id_field(), "PAN", 1, 3);
refactor(cpufeat): enable FEAT_VHE for FEAT_STATE_CHECKED At the moment we only support FEAT_VHE to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_FEAT_VHE=2), by splitting is_armv8_1_vhe_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access VHE related registers. Also move the context saving code from assembly to C, and use the new is_feat_vhe_supported() function to guard its execution. Enable VHE in its runtime detection version for all FVP builds. Change-Id: Ib397cd0c83e8c709bd6fed603560e39901fa672b Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_VHE, read_feat_vhe_id_field(), "VHE", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.2 features */
feat(cpufeat): enable FEAT_SVE for FEAT_STATE_CHECKED Add support for runtime detection (ENABLE_SVE_FOR_NS=2), by splitting sve_supported() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we do SVE specific setup. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I1caaba2216e8e2a651452254944a003607503216 Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt;
2 years ago
check_feature(ENABLE_SVE_FOR_NS, read_feat_sve_id_field(),
"SVE", 1, 1);
refactor(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED At the moment we only support FEAT_RAS to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (FEAT_RAS=2), by splitting is_armv8_2_feat_ras_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access RAS related registers. Also move the context saving code from assembly to C, and use the new is_feat_ras_supported() function to guard its execution. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I30498f72fd80b136850856244687400456a03d0e Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Signed-off-by: Manish Pandey &lt;manish.pandey2@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_RAS, read_feat_ras_id_field(), "RAS", 1, 2);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.3 features */
read_feat_pauth();
/* v8.4 features */
refactor(cpufeat): enable FEAT_DIT for FEAT_STATE_CHECKED At the moment we only support FEAT_DIT to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_DIT=2), by splitting is_armv8_4_dit_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed). We use ENABLE_DIT in two occassions in assembly code, where we just set the DIT bit in the DIT system register. Protect those two cases by reading the CPU ID register when ENABLE_DIT is set to 2. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I506d352f18e23c60db8cdf08edb449f60adbe098 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_DIT, read_feat_dit_id_field(), "DIT", 1, 1);
refactor(amu): unify ENABLE_AMU and ENABLE_FEAT_AMUv1 So far we have the ENABLE_AMU build option to include AMU register handling code for enabling and context switch. There is also an ENABLE_FEAT_AMUv1 option, solely to protect the HAFGRTR_EL2 system register handling. The latter needs some alignment with the new feature scheme, but it conceptually overlaps with the ENABLE_AMU option. Since there is no real need for two separate options, unify both into a new ENABLE_FEAT_AMU name in a first step. This is mostly just renaming at this point, a subsequent patch will make use of the new feature handling scheme. Change-Id: I97d8a55bdee2ed1e1509fa9f2b09fd0bdd82736e Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_AMU, read_feat_amu_id_field(),
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
"AMUv1", 1, 2);
fix(mpam): refine MPAM initialization and enablement process Restricts MPAM to only NS world and enables trap to EL3 for access of MPAM registers from lower ELs of Secure and Realm world. This patch removes MPAM enablement from global context and adds it to EL3 State context which enables/disables MPAM during world switches. Renamed ENABLE_MPAM_FOR_LOWER_ELS to ENABLE_FEAT_MPAM and removed mpam_init_el3() as RESET behaviour is trapping. Signed-off-by: Arvind Ram Prakash &lt;arvind.ramprakash@arm.com&gt; Change-Id: I131f9dba5df236a71959b2d425ee11af7f3c38c4
1 year ago
check_feature(ENABLE_FEAT_MPAM, read_feat_mpam_version(),
fix(mpam): feat_detect: support major/minor The MPAM CPU ID version number is split between two CPU ID register fields, with the second being a fractional field, allowing for instance for a &#34;MPAM v1.1&#34; number. The read_feat_mpam_version() function merges those two fields to form a &#34;4.4&#34; fixed point fractional number, but the limit check in the check_feature() function was not taking this into account. To support MPAM major version 1, extend the limit from &#34;1&#34; to &#34;17&#34;, to cover the current maximum version of &#34;MPAM v1.1&#34;. This fixes FVP runs with &#34;has_mpam=1&#34; and FEATURE_DETECTION enabled. Change-Id: Icb557741d597e4e43eaf658b78f18af6e9fb439e Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
"MPAM", 1, 17);
refactor(cpufeat): enable FEAT_NV2 for FEAT_STATE_CHECKED At the moment we only support for FEAT_NV2 to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (CTX_INCLUDE_NEVE_REGS=2), by splitting get_armv8_4_feat_nv_support() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access the VNCR_EL2 system register. Also move the context saving code from assembly to C, and use the new is_feat_nv2_supported() function to guard its execution. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I85b080641995fb72cfd4ac933f7a3f75770c2cb9 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(CTX_INCLUDE_NEVE_REGS, read_feat_nv_id_field(),
"NV2", 2, 2);
refactor(cpufeat): align FEAT_SEL2 to new feature handling In ARMv8.4, the EL2 exception level got added to the secure world. Adapt and rename the existing is_armv8_4_sel2_present() function, to align its handling with the other CPU features. Change-Id: If11e1942fdeb63c63f36ab9e89be810347d1a952 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_SEL2, read_feat_sel2_id_field(),
"SEL2", 1, 1);
refactor(trf): enable FEAT_TRF for FEAT_STATE_CHECKED At the moment we only support FEAT_TRF to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_TRF_FOR_NS=2), by splitting is_feat_trf_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access TRF related registers. Also move the context saving code from assembly to C, and use the new is_feat_trf_supported() function to guard its execution. The FVP platform decided to compile in support unconditionally (=1), even though FEAT_TRF is an ARMv8.4 feature, so is not available with the FVP model&#39;s default command line. Change that to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: Ia97b01adbe24970a4d837afd463dc5506b7295a3 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_TRF_FOR_NS, read_feat_trf_id_field(),
"TRF", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.5 features */
refactor(mte): deprecate CTX_INCLUDE_MTE_REGS Currently CTX_INCLUDE_MTE_REGS is used for dual purpose, to enable allocation tags register and to context save and restore them and also to check if mte feature is available. To make it more meaningful, remove CTX_INCLUDE_MTE_REGS and introduce FEAT_MTE. This would enable allocation tags register when FEAT_MTE is enabled and also supported from platform. Also arch features can be conditionally enabled disabled based on arch version from `make_helpers/arch_features.mk` Change-Id: Ibdd2d43874634ad7ddff93c7edad6044ae1631ed Signed-off-by: Govindraj Raja &lt;govindraj.raja@arm.com&gt;
11 months ago
check_feature(ENABLE_FEAT_MTE, read_feat_mte_id_field(), "MTE",
MTE_IMPLEMENTED_EL0, MTE_IMPLEMENTED_ASY);
refactor(cpufeat): enable FEAT_RNG for FEAT_STATE_CHECKED At the moment we only support for FEAT_RNG to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (FEAT_RNG=2), by splitting is_armv8_5_rng_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access the RNDRRS system register. Change the QEMU platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I1a4a538d5ad395fead7324f297d0056bda4f84cb Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_RNG, read_feat_rng_id_field(), "RNG", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
read_feat_bti();
feat(rng-trap): add EL3 support for FEAT_RNG_TRAP FEAT_RNG_TRAP introduces support for EL3 trapping of reads of the RNDR and RNDRRS registers, which is enabled by setting the SCR_EL3.TRNDR bit. This patch adds a new build flag ENABLE_FEAT_RNG_TRAP that enables the feature. This feature is supported only in AArch64 state from Armv8.5 onwards. Signed-off-by: Juan Pablo Conde &lt;juanpablo.conde@arm.com&gt; Change-Id: Ia9f17aef3444d3822bf03809036a1f668c9f2d89
2 years ago
read_feat_rng_trap();
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.6 features */
refactor(amu): use new AMU feature check routines The AMU extension code was using its own feature detection routines. Replace them with the generic CPU feature handlers (defined in arch_features.h), which get updated to cover the v1p1 variant as well. Change-Id: I8540f1e745d7b02a25a6c6cdf2a39d6f5e21f2aa Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_AMUv1p1, read_feat_amu_id_field(),
"AMUv1p1", 2, 2);
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_FGT, read_feat_fgt_id_field(), "FGT", 1, 1);
refactor(cpufeat): enable FEAT_ECV for FEAT_STATE_CHECKED At the moment we only support FEAT_ECV to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_FEAT_ECV=2), by splitting is_feat_ecv_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access the CNTPOFF_EL2 system register. Also move the context saving code from assembly to C, and use the new is_feat_ecv_supported() function to guard its execution. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I4acd5384929f1902b62a87ae073aafa1472cd66b Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_ECV, read_feat_ecv_id_field(), "ECV", 1, 2);
refactor(cpufeat): enable FEAT_TWED for FEAT_STATE_CHECKED At the moment we only support FEAT_TWED to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_FEAT_TWED=2), by splitting is_armv8_6_twed_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we set the trap delay time. Change the FVP platform default to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I58626230ef0af49886c0a197abace01e81f661d2 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_TWED, read_feat_twed_id_field(),
"TWED", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
refactor(pmu): convert FEAT_MTPMU to C and move to persistent register init The FEAT_MTPMU feature disable runs very early after reset. This means, it needs to be written in assembly, since the C runtime has not been initialised yet. However, there is no need for it to be initialised so soon. The PMU state is only relevant after TF-A has relinquished control. The code to do this is also very verbose and difficult to read. Delaying the initialisation allows for it to happen with the rest of the PMU. Align with FEAT_STATE in the process. BREAKING CHANGE: This patch explicitly breaks the EL2 entry path. It is currently unsupported. Signed-off-by: Boyan Karatotev &lt;boyan.karatotev@arm.com&gt; Change-Id: I2aa659d026fbdb75152469f6d19812ece3488c6f
2 years ago
/*
* even though this is a "DISABLE" it does confusingly perform feature
* enablement duties like all other flags here. Check it against the HW
* feature when we intend to diverge from the default behaviour
*/
check_feature(DISABLE_MTPMU, read_feat_mtpmu_id_field(), "MTPMU", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v8.7 features */
feat(cpufeat): extend check_feature() to deal with min/max So far the check_feature() function compares the subfield of a CPU ID register against 0, to learn if a feature is enabled or not. This is problematic for checks that require a certain revision of a feature, so we should check against a minimum version number instead. On top of that we might need to add code to support newer versions of a feature, so we should be alerted if new hardware introduces a higher number. Extend the check_feature() function to take two extra arguments: the minimum version, and the greatest currently known number. Then make sure that the CPU ID field is in this range. Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_HCX, read_feat_hcx_id_field(), "HCX", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
feat(tcr2): support FEAT_TCR2 Arm v8.9 introduces FEAT_TCR2, adding extended translation control registers. Support this, context switching TCR2_EL2 and disabling traps so lower ELs can access the new registers. Change the FVP platform to default to handling this as a dynamic option so the right decision can be made by the code at runtime. Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt; Change-Id: I297452acd8646d58bac64fc15e05b06a543e5148
2 years ago
/* v8.9 features */
refactor(cpufeat): introduce wrapper macro for read_feat_...() functions At the moment we have some elaborate, but very schematic functions to allow checking for CPU feature enablement. Adding some more becomes tedious and is also error-prone. Provide two wrapper macros that reduce most of the features to a single line: - CREATE_FEATURE_FUNCS(name, idreg, idfield, guard) creates two functions read_&lt;name&gt;_id_field() and is_&lt;name&gt;_supported(), that check the 4-bit CPU ID field starting at bit &lt;idfield&gt; in &lt;idreg&gt; for being not 0, and compares it against the build time &lt;guard&gt; symbol. For the usual feature (like PAN) this looks like: CREATE_FEATURE_FUNCS(feat_pan, id_aa64mmfr1_el1, ID_AA64MMFR1_EL1_PAN_SHIFT, ENABLE_FEAT_PAN) - CREATE_FEATURE_FUNCS_VER(name, read_func, idvalue, guard) creates one function to check for a certain CPU ID field *value*, so when &#34;!= 0&#34; is not sufficient. It&#39;s meant to be used in addition to the above macro, since that generates the CPU ID field accessor function: CREATE_FEATURE_FUNCS(feat_amu, id_aa64pfr0_el1, ID_AA64PFR0_AMU_SHIFT, ENABLE_FEAT_AMU) CREATE_FEATURE_FUNCS_VER(feat_amuv1p1, read_feat_amu_id_field, ID_AA64PFR0_AMU_V1P1, ENABLE_FEAT_AMUv1p1) Describe the existing feature accessor functions using those new macros, to reduce the size of the file, improve readability and decrease the possibility of (copy&amp;paste) bugs. Change-Id: Ib136a875b4857058ff561c4635ace344006f29bf Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_TCR2, read_feat_tcr2_id_field(),
feat(tcr2): support FEAT_TCR2 Arm v8.9 introduces FEAT_TCR2, adding extended translation control registers. Support this, context switching TCR2_EL2 and disabling traps so lower ELs can access the new registers. Change the FVP platform to default to handling this as a dynamic option so the right decision can be made by the code at runtime. Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt; Change-Id: I297452acd8646d58bac64fc15e05b06a543e5148
2 years ago
"TCR2", 1, 1);
feat(pie/por): support permission indirection and overlay Arm v8.9 introduces a series of features providing a new way to set memory permissions. Instead of directly encoding the permissions in the page tables the PTEs contain indexes into an array of permissions stored in system registers, allowing greater flexibility and density of encoding. Enable access to these features for EL2 and below, context switching the newly added EL2 registers as appropriate. Since all of FEAT_S[12]P[IO]E are separately discoverable we have separate build time options for enabling them, but note that there is overlap in the registers that they implement and the enable bit required for lower EL access. Change the FVP platform to default to handling them as dynamic options so the right decision can be made by the code at runtime. Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt; Change-Id: Icf89e444e39e1af768739668b505661df18fb234
2 years ago
check_feature(ENABLE_FEAT_S2PIE, read_feat_s2pie_id_field(),
"S2PIE", 1, 1);
check_feature(ENABLE_FEAT_S1PIE, read_feat_s1pie_id_field(),
"S1PIE", 1, 1);
check_feature(ENABLE_FEAT_S2POE, read_feat_s2poe_id_field(),
"S2POE", 1, 1);
check_feature(ENABLE_FEAT_S1POE, read_feat_s1poe_id_field(),
"S1POE", 1, 1);
feat(mte): adds feature detection for MTE_PERM Adds feature detection for v8.9 feature FEAT_MTE_PERM. Adds respective ID_AA64PFR2_EL1 definitions and ENABLE_FEAT_MTE_PERM define. Change-Id: If24b42f1207154e639016b0b840b2d91c6ee13d4 Signed-off-by: Maksims Svecovs &lt;maksims.svecovs@arm.com&gt; Signed-off-by: Harrison Mutai &lt;harrison.mutai@arm.com&gt;
2 years ago
check_feature(ENABLE_FEAT_MTE_PERM, read_feat_mte_perm_id_field(),
"MTE_PERM", 1, 1);
feat(cpufeat): add feature detection for FEAT_CSV2_3 This feature provides support to context save the SCXTNUM_ELx register. FEAT_CSV2_3 implies the implementation of FEAT_CSV2_2. FEAT_CSV2_3 is supported in AArch64 state only and is an optional feature in Arm v8.0 implementations. This patch adds feature detection for v8.9 feature FEAT_CSV2_3, adds macros for ID_AA64PFR0_EL1.CSV2 bits [59:56] for detecting FEAT_CSV2_3 and macro for ENABLE_FEAT_CSV2_3. Change-Id: Ida9f31e832b5f11bd89eebd6cc9f10ddad755c14 Signed-off-by: Sona Mathew &lt;sonarebecca.mathew@arm.com&gt;
1 year ago
check_feature(ENABLE_FEAT_CSV2_3, read_feat_csv2_id_field(),
"CSV2_3", 3, 3);
feat(tcr2): support FEAT_TCR2 Arm v8.9 introduces FEAT_TCR2, adding extended translation control registers. Support this, context switching TCR2_EL2 and disabling traps so lower ELs can access the new registers. Change the FVP platform to default to handling this as a dynamic option so the right decision can be made by the code at runtime. Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt; Change-Id: I297452acd8646d58bac64fc15e05b06a543e5148
2 years ago
feat(brbe): add brbe under feature detection mechanism This change adds &#34;FEAT_BRBE&#34; to be part of feature detection mechanism. Previously feature enablement flags were of boolean type, possessing either 0 or 1. With the introduction of feature detection procedure we now support three states for feature enablement build flags(0 to 2). Accordingly, &#34;ENABLE_BRBE_FOR_NS&#34; flag is now modified from boolean to numeric type to align with the feature detection. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: I1eb52863b4afb10b808e2f0b6584a8a210d0f38c
3 years ago
/* v9.0 features */
refactor(brbe): enable FEAT_BRBE for FEAT_STATE_CHECKED At the moment we only support FEAT_BRBE to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_BRBE_FOR_NS=2), by splitting is_feat_brbe_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access BRBE related registers. The FVP platform decided to compile in support unconditionally (=1), even though FEAT_BRBE is an ARMv9 feature, so is not available with the FVP model&#39;s default command line. Change that to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: I5f2e2c9648300f65f0fa9a5f8e2f34e73529d053 Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_BRBE_FOR_NS, read_feat_brbe_id_field(),
"BRBE", 1, 2);
refactor(trbe): enable FEAT_TRBE for FEAT_STATE_CHECKED At the moment we only support FEAT_TRBE to be either unconditionally compiled in, or to be not supported at all. Add support for runtime detection (ENABLE_TRBE_FOR_NS=2), by splitting is_feat_trbe_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access TRBE related registers. The FVP platform decided to compile in support unconditionally (=1), even though FEAT_TRBE is an ARMv9 feature, so is not available with the FVP model&#39;s default command line. Change that to the now supported dynamic option (=2), so the right decision can be made by the code at runtime. Change-Id: Iee7f88ea930119049543a8a4a105389997e7692c Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
2 years ago
check_feature(ENABLE_TRBE_FOR_NS, read_feat_trbe_id_field(),
"TRBE", 1, 1);
feat(brbe): add brbe under feature detection mechanism This change adds &#34;FEAT_BRBE&#34; to be part of feature detection mechanism. Previously feature enablement flags were of boolean type, possessing either 0 or 1. With the introduction of feature detection procedure we now support three states for feature enablement build flags(0 to 2). Accordingly, &#34;ENABLE_BRBE_FOR_NS&#34; flag is now modified from boolean to numeric type to align with the feature detection. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: I1eb52863b4afb10b808e2f0b6584a8a210d0f38c
3 years ago
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
/* v9.2 features */
feat(cpufeat): enable FEAT_SME for FEAT_STATE_CHECKED Add support for runtime detection (ENABLE_SME_FOR_NS=2), by splitting feat_sme_supported() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we do SME specific setup. Change the FVP platform default to the now supported dynamic option (=2),so the right decision can be made by the code at runtime. Change-Id: Ida9ccf737db5be20865b84f42b1f9587be0626ab Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt;
2 years ago
check_feature(ENABLE_SME_FOR_NS, read_feat_sme_id_field(),
"SME", 1, 2);
feat(sme): enable SME2 functionality for NS world FEAT_SME2 is an extension of FEAT_SME and an optional feature from v9.2. Its an extension of SME, wherein it not only processes matrix operations efficiently, but also provides outer-product instructions to accelerate matrix operations. It affords instructions for multi-vector operations. Further, it adds an 512 bit architectural register ZT0. This patch implements all the changes introduced with FEAT_SME2 to ensure that the instructions are allowed to access ZT0 register from Non-secure lower exception levels. Additionally, it adds support to ensure FEAT_SME2 is aligned with the existing FEATURE DETECTION mechanism, and documented. Change-Id: Iee0f61943304a9cfc3db8f986047b1321d0a6463 Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt;
2 years ago
check_feature(ENABLE_SME2_FOR_NS, read_feat_sme_id_field(),
"SME2", 2, 2);
feat(gcs): support guarded control stack Arm v9.4 introduces support for Guarded Control Stack, providing mitigations against some forms of RPO attacks and an efficient mechanism for obtaining the current call stack without requiring a full stack unwind. Enable access to this feature for EL2 and below, context switching the newly added EL2 registers as appropriate. Change the FVP platform to default to handling this as a dynamic option so the right decision can be made by the code at runtime. Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt; Change-Id: I691aa7c22e3547bb3abe98d96993baf18c5f0e7b
2 years ago
/* v9.4 features */
check_feature(ENABLE_FEAT_GCS, read_feat_gcs_id_field(), "GCS", 1, 1);
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
read_feat_rme();
refactor(cpufeat): check FEAT_FGT in a new way To implement proper runtime checking of features, and to be able to extend feat_detect.c to catch other cases, rework the FEAT_FGT check to directly call a generic function instead of providing a trivial specific one. The #ifdef is moved into the function, and rewritten as a proper C if statement. We need to force the compiler to inline that function, otherwise the optimisation won&#39;t work, once we exceed a certain number of callers. This starts with FEAT_FGT, but all the other features will be moved over eventually, in separate patches. For all features checked this way, we delay the panic() until after every feature has been checked, to list them all during one run. Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt; Change-Id: Ic576922ff2c4f8d3c1b87b5843b3626729fe4514
2 years ago
if (tainted) {
panic();
}
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro &#34;FEATURE_DETECTION&#34;, which is currently being disabled by default. The &#34;FEATURE_DETECTION&#34; macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this &#34;FEATURE_DETECTION&#34; flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
}