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 ...

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 ...

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 ...

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 ...

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 ...