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.
12089 Commits
5 Branches
114 Tags
55 MiB
Tree: ff49103660
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'ff49103660'
${ noResults }
arm-trusted-firmware/common/feat_detect.c

339 lines
11 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
/*
* Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.
*
* 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_SB (Speculation Barrier)
*****************************************/
static void read_feat_sb(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_SB == 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_0_feat_sb_present(), "SB");
#endif
}
/******************************************************
* Feature : FEAT_CSV2_2 (Cache Speculation Variant 2)
*****************************************************/
static void read_feat_csv2_2(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_CSV2_2 == 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_0_feat_csv2_2_present(), "CSV2_2");
#endif
}
/***********************************************
* Feature : FEAT_PAN (Privileged Access Never)
**********************************************/
static void read_feat_pan(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_PAN == 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_1_pan_present(), "PAN");
#endif
}
/******************************************************
* Feature : FEAT_VHE (Virtualization Host Extensions)
*****************************************************/
static void read_feat_vhe(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_VHE == 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_1_vhe_present(), "VHE");
#endif
}
/*******************************************************************************
* Feature : FEAT_RAS (Reliability, Availability, and Serviceability Extension)
******************************************************************************/
static void read_feat_ras(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 (RAS_EXTENSION == 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_2_feat_ras_present(), "RAS");
#endif
}
/************************************************
* 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_DIT (Data Independent Timing Instructions)
***********************************************************/
static void read_feat_dit(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_DIT == 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_4_feat_dit_present(), "DIT");
#endif
}
/****************************************************************************
* Feature : FEAT_MPAM (Memory Partitioning and Monitoring (MPAM) Extension)
***************************************************************************/
static void read_feat_mpam(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_MPAM_FOR_LOWER_ELS == 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_mpam_version() != 0U, "MPAM");
#endif
}
/**************************************************************
* Feature : FEAT_NV2 (Enhanced Nested Virtualization Support)
*************************************************************/
static void read_feat_nv2(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 (CTX_INCLUDE_NEVE_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
unsigned int nv = get_armv8_4_feat_nv_support();
feat_detect_panic((nv == ID_AA64MMFR2_EL1_NV2_SUPPORTED), "NV2");
#endif
}
/***********************************
* Feature : FEAT_SEL2 (Secure EL2)
**********************************/
static void read_feat_sel2(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_SEL2 == 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_4_sel2_present(), "SEL2");
#endif
}
/****************************************************
* Feature : FEAT_TRF (Self-hosted Trace Extensions)
***************************************************/
static void read_feat_trf(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_TRF_FOR_NS == 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_arm8_4_feat_trf_present(), "TRF");
#endif
}
/************************************************
* Feature : FEAT_MTE (Memory Tagging Extension)
***********************************************/
static void read_feat_mte(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 (CTX_INCLUDE_MTE_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
unsigned int mte = get_armv8_5_mte_support();
feat_detect_panic((mte != MTE_UNIMPLEMENTED), "MTE");
#endif
}
/***********************************************
* Feature : FEAT_RNG (Random Number Generator)
**********************************************/
static void read_feat_rng(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 == 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_rng_present(), "RNG");
#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_AMUv1p1 (AMU Extensions v1.1)
**********************************************/
static void read_feat_amuv1p1(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_AMUv1p1 == 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_6_feat_amuv1p1_present(), "AMUv1p1");
#endif
}
/*******************************************************
* Feature : FEAT_ECV (Enhanced Counter Virtualization)
******************************************************/
static void read_feat_ecv(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_ECV == 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
unsigned int ecv = get_armv8_6_ecv_support();
feat_detect_panic(((ecv == ID_AA64MMFR0_EL1_ECV_SUPPORTED) ||
(ecv == ID_AA64MMFR0_EL1_ECV_SELF_SYNCH)), "ECV");
#endif
}
refactor(twed): improve TWED enablement in EL-3 The current implementation uses plat_arm API under generic code. &#34;plat_arm&#34; API is a convention used with Arm common platform layer and is reserved for that purpose. In addition, the function has a weak definition which is not encouraged in TF-A. Henceforth, removing the weak API with a configurable macro &#34;TWED_DELAY&#34; of numeric data type in generic code and simplifying the implementation. By default &#34;TWED_DELAY&#34; is defined to zero, and the delay value need to be explicitly set by the platforms during buildtime. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: I25cd6f628e863dc40415ced3a82d0662fdf2d75a
3 years ago
/***********************************************************
* Feature : FEAT_TWED (Delayed Trapping of WFE Instruction)
**********************************************************/
static void read_feat_twed(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_TWED == FEAT_STATE_ALWAYS)
refactor(twed): improve TWED enablement in EL-3 The current implementation uses plat_arm API under generic code. &#34;plat_arm&#34; API is a convention used with Arm common platform layer and is reserved for that purpose. In addition, the function has a weak definition which is not encouraged in TF-A. Henceforth, removing the weak API with a configurable macro &#34;TWED_DELAY&#34; of numeric data type in generic code and simplifying the implementation. By default &#34;TWED_DELAY&#34; is defined to zero, and the delay value need to be explicitly set by the platforms during buildtime. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: I25cd6f628e863dc40415ced3a82d0662fdf2d75a
3 years ago
feat_detect_panic(is_armv8_6_twed_present(), "TWED");
#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
/**************************************************
* 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 */
read_feat_sb();
read_feat_csv2_2();
/* v8.1 features */
read_feat_pan();
read_feat_vhe();
/* v8.2 features */
read_feat_ras();
/* v8.3 features */
read_feat_pauth();
/* v8.4 features */
read_feat_dit();
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_AMUv1, read_feat_amu_id_field(),
"AMUv1", 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
read_feat_mpam();
read_feat_nv2();
read_feat_sel2();
read_feat_trf();
/* v8.5 features */
read_feat_mte();
read_feat_rng();
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 */
read_feat_amuv1p1();
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(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_ecv();
refactor(twed): improve TWED enablement in EL-3 The current implementation uses plat_arm API under generic code. &#34;plat_arm&#34; API is a convention used with Arm common platform layer and is reserved for that purpose. In addition, the function has a weak definition which is not encouraged in TF-A. Henceforth, removing the weak API with a configurable macro &#34;TWED_DELAY&#34; of numeric data type in generic code and simplifying the implementation. By default &#34;TWED_DELAY&#34; is defined to zero, and the delay value need to be explicitly set by the platforms during buildtime. Signed-off-by: Jayanth Dodderi Chidanand &lt;jayanthdodderi.chidanand@arm.com&gt; Change-Id: I25cd6f628e863dc40415ced3a82d0662fdf2d75a
3 years ago
read_feat_twed();
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(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 */
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
}