Merge changes from topic "bk/pabandon_cleanup" into integration

* changes:
feat(cpus): add pabandon support to the Alto cpu
feat(psci): optimise clock init on a pabandon
feat(psci): check that

Merge changes from topic "bk/pabandon_cleanup" into integration

* changes:
feat(cpus): add pabandon support to the Alto cpu
feat(psci): optimise clock init on a pabandon
feat(psci): check that CPUs handled a pabandon
feat(psci): make pabandon support generic
refactor(psci): unify coherency exit between AArch64 and AArch32
refactor(psci): absorb psci_power_down_wfi() into common code
refactor(platforms): remove usage of psci_power_down_wfi
fix(cm): disable SPE/TRBE correctly

show more ...

fix(cm): disable SPE/TRBE correctly

SPE and TRBE are unusual features. They have multi-bit enables whose
function is not immediately apparent and disabling them is not
straightforward.

While attemp

fix(cm): disable SPE/TRBE correctly

SPE and TRBE are unusual features. They have multi-bit enables whose
function is not immediately apparent and disabling them is not
straightforward.

While attempting to figure this out, the disables were made a mess of.
Patch fc7dca72b began changing the owning security state of SPE and
TRBE. This was first used in patch 79c0c7fac0 with calls to
spe_disable() and trbe_disbale(). However, patch 13f4a2525 reverted the
security state ownership, making the spe_disable() and trbe_disable()
redundant and their comments incorrect - the DoS protection is achieved
by the psb/tsb barriers on context switch, introduces separately in
f80887337 and 73d98e375.

Those patches got the behaviour full circle to what it was in fc7dca72b
so the disables can be fully removed for clarity.

However, the original method for disabling these features is not fully
correct - letting the "disabled" state be all zeroes made the features
seem enabled for secure world but they would trap. That is not a problem
while secure world doesn't use them, but could lead to some confusing
debugging in the future. NS and Realm worlds were not affected. This
patch fully establishes the pattern for SPE and TRBE's enablement,
documents it, and implements it such.

The description comments in the features boil down to 2 rules. There is
a third rule possible:
3. To enable TRBE/SPE for world X with a dirty buffer:
* world X owns the buffer
* trapping enabled
This is not listed as it would not work correctly with
SMCCC_ARCH_FEATURE_AVAILABILITY which relies on trapping to be disabled
to report correctly. If that is ever implemented, the SMCCC
implementation should be considered too.

Change-Id: I5588a3d5fc074c2445470954d8c3b172bec77d43
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge changes from topic "bk/smccc_feature" into integration

* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change own

Merge changes from topic "bk/smccc_feature" into integration

* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change owning security state when a feature is disabled

show more ...

refactor(cm): change owning security state when a feature is disabled

SPE and TRBE don't have an outright EL3 disable, there are only
constraints on what's allowed. Since we only enable them for NS

refactor(cm): change owning security state when a feature is disabled

SPE and TRBE don't have an outright EL3 disable, there are only
constraints on what's allowed. Since we only enable them for NS at the
moment, we want NS to own the buffers even when the feature should be
"disabled" for a world. This means that when we're running in NS
everything is as normal but when running in S/RL then tracing is
prohibited (since the buffers are owned by NS). This allows us to fiddle
with context a bit more without having to context switch registers.

Change-Id: Ie1dc7c00e4cf9bcc746f02ae43633acca32d3758
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge "fix(brbe): allow RME builds with BRBE" into integration

fix(brbe): allow RME builds with BRBE

It used to be the case that a FEAT_RME build could not be built with
FEAT_BRBE support. BRBE doesn't have a 3-world aware disable and
MDCR_EL3 was not context s

fix(brbe): allow RME builds with BRBE

It used to be the case that a FEAT_RME build could not be built with
FEAT_BRBE support. BRBE doesn't have a 3-world aware disable and
MDCR_EL3 was not context switched to allow for disabling in Realm world.

As of commit 123002f9171384d976d95935b7f566740d69cc68 MDCR_EL3 is
context switched. Since the flag for BRBE support is
ENABLE_BRBE_FOR_NS, move brbe_enable() to only happen for NS world. The
other worlds will see BRBE disabled and branch recording prohibited.
This allows for a build with both RME and BRBE.

Note that EL2 BRBE registers are not context switched. Further work is
needed if non-NS support is required.

Change-Id: I82f0f08399dcd080902477dc9636bc4541685f89
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge "feat(cm): context switch MDCR_EL3 register" into integration

feat(cm): context switch MDCR_EL3 register

Currently MDCR_EL3 register value is same for all the
worlds(Non-secure, Secure, Realm and Root).

With this approach, features enable/disable settings
rem

feat(cm): context switch MDCR_EL3 register

Currently MDCR_EL3 register value is same for all the
worlds(Non-secure, Secure, Realm and Root).

With this approach, features enable/disable settings
remain same across all the worlds. This is not ideal as
there must be flexibility in controlling feature as per
the requirements for individual world.

The patch addresses this by providing MDCR_EL3 a per world
value. Features with identical values for all the worlds are
grouped under ``manage_extensions_common`` API.

Change-Id: Ibc068d985fe165d8cb6d0ffb84119bffd743b3d1
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>

show more ...

Merge changes from topic "bk/context_refactor" into integration

* changes:
refactor(amu): separate the EL2 and EL3 enablement code
refactor(cpufeat): separate the EL2 and EL3 enablement code

refactor(cpufeat): separate the EL2 and EL3 enablement code

Combining the EL2 and EL3 enablement code necessitates that it must be
called at el3_exit, which is the only place with enough context to

refactor(cpufeat): separate the EL2 and EL3 enablement code

Combining the EL2 and EL3 enablement code necessitates that it must be
called at el3_exit, which is the only place with enough context to make
the decision of what needs to be set.
Decouple them to allow them to be called from elsewhere.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I147764c42771e7d4100699ec8fae98dac0a505c0

show more ...

Merge changes from topic "feat_state_part2" into integration

* changes:
refactor(trf): enable FEAT_TRF for FEAT_STATE_CHECKED
refactor(brbe): enable FEAT_BRBE for FEAT_STATE_CHECKED
refactor(t

Merge changes from topic "feat_state_part2" into integration

* changes:
refactor(trf): enable FEAT_TRF for FEAT_STATE_CHECKED
refactor(brbe): enable FEAT_BRBE for FEAT_STATE_CHECKED
refactor(trbe): enable FEAT_TRBE for FEAT_STATE_CHECKED
fix(cpufeat): context-switch: move FGT availability check to callers
feat(cpufeat): extend check_feature() to deal with min/max
refactor(cpufeat): wrap CPU ID register field isolation

show more ...

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 dete

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'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 <andre.przywara@arm.com>

show more ...

Merge changes from topic "jc/detect_feat" into integration

* changes:
feat(trbe): add trbe under feature detection mechanism
feat(brbe): add brbe under feature detection mechanism

feat(brbe): add brbe under feature detection mechanism

This change adds "FEAT_BRBE" to be part of feature detection mechanism.

Previously feature enablement flags were of boolean type, possessing
e

feat(brbe): add brbe under feature detection mechanism

This change adds "FEAT_BRBE" 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, "ENABLE_BRBE_FOR_NS" flag is now modified from boolean
to numeric type to align with the feature detection.

Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: I1eb52863b4afb10b808e2f0b6584a8a210d0f38c

show more ...

Merge "feat(brbe): add BRBE support for NS world" into integration

feat(brbe): add BRBE support for NS world

This patch enables access to the branch record buffer control registers
in non-secure EL2 and EL1 using the new build option ENABLE_BRBE_FOR_NS.
It is disab

feat(brbe): add BRBE support for NS world

This patch enables access to the branch record buffer control registers
in non-secure EL2 and EL1 using the new build option ENABLE_BRBE_FOR_NS.
It is disabled for all secure world, and cannot be used with ENABLE_RME.

This option is disabled by default, however, the FVP platform makefile
enables it for FVP builds.

Signed-off-by: John Powell <john.powell@arm.com>
Change-Id: I576a49d446a8a73286ea6417c16bd0b8de71fca0

show more ...