feat(psci): remove cpu context init by index
Currently, the calling core (meaning the core which received the call to
CPU_ON or the powerdown path of CPU_SUSPEND on the same core) is in
charge of initialising the context for the waking core (the warmboot
entrypoint for both). This is convenient because the calling core can
write the context while in coherency and the waking core will only need
the context after its entered coherency. This avoids any cache
maintenance and makes communication simple.
However, this has 3 main problems:
a) asymmetric feature support is problematic - the calling core has no
way of knowing the feature set of the waking core. If the two
diverge, the architectural feature discovery via ID registers breaks
down. We've thus far "fixed" this on a case by case basis which
doesn't scale and introduces redundancy.
b) powerdown abandon (pabandon) introduces a contradiction - the calling
core has to initialise the context for when the core wakes up, but
should the core not powerdown it needs its old context intact. The only
way to work around this is by keeping two copies of context which
incurs a runtime and memory overhead.
c) cm_prepare_el3_exit[_ns]() doesn't have access to the entrypoint but needs
it to make initialisation decisions. We can infer some of this from
registers that have already been written but this is awkwardly
limiting for what we can do. This also necessitates the split from
the context initialisation.
We can solve all three by a making a core be in full ownership of its
own context. The calling core then only writes entrypoint information
and nothing else. The waking core then initialises its own context as it
sees fit with full knowledge of the whole picture.
The only tricky bit is cache coherency - the waking core has to be able
to coherently observe its new entrypoint. Calling cores will write to
the shared region with coherent caches on. If we make sure to read the
context only after the waking core has entered coherency, then we can
avoid cache operations and let hardware handle everything.
We can skip the spsr check for FEAT_TCR2 as it doesn't make a
difference. We can also skip enabling it twice from generic code.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I86e7fe8b698191fc3b469e5ced1fd010f8754b0e
diff --git a/docs/components/context-management-library.rst b/docs/components/context-management-library.rst
index 8cb1ace..cef6fba 100644
--- a/docs/components/context-management-library.rst
+++ b/docs/components/context-management-library.rst
@@ -106,7 +106,6 @@
#define FEAT_STATE_DISABLED 0
#define FEAT_STATE_ENABLED 1
#define FEAT_STATE_CHECK 2
- #define FEAT_STATE_CHECK_ASYMMETRIC 3
A pattern is established for feature enablement behavior.
Each feature must support the 3 possible values with rigid semantics.
@@ -120,15 +119,15 @@
- **FEAT_STATE_CHECK** - same as ``FEAT_STATE_ALWAYS`` except that the feature's
existence will be checked at runtime. Default on dynamic platforms (example: FVP).
-- **FEAT_STATE_CHECK_ASYMMETRIC** - same as ``FEAT_STATE_CHECK`` except that the feature's
- existence is asymmetric across cores, which requires the feature existence is checked
- during warmboot path also. Note that only limited number of features can be asymmetric.
-
.. note::
- Only limited number of features can be ``FEAT_STATE_CHECK_ASYMMETRIC`` this is due to
- the fact that Operating systems are designed for SMP systems.
- There are no clear guidelines what kind of mismatch is allowed but following pointers
- can help making a decision
+
+ In general, it is assumed that all cores will support the same set of
+ architectural features (features will be symmetrical). However, there are
+ cases where this is impractical to achieve. Only some features can be
+ mismatched among cores and this is the exception rather than the rule. This
+ is due to the fact that Operating systems are designed for SMP systems. There
+ are no clear guidelines what kind of mismatch is allowed but following
+ pointers can help in making a decision:
- All mandatory features must be symmetric.
- Any feature that impacts the generation of page tables must be symmetric.
@@ -136,8 +135,9 @@
- Features related with profiling, debug and trace could be asymmetric
- Migration of vCPU/tasks between CPUs should not cause an error
- Whenever there is asymmetric feature support is added for a feature TF-A need to add
- feature specific code in context management code.
+ TF-A caters for mismatched features, however, this is not regularly tested
+ for all features and may not work as expected, even without considering OS
+ support.
.. note::
``FEAT_RAS`` is an exception here, as it impacts the execution of EL3 and
@@ -345,9 +345,9 @@
|Context Init WarmBoot|
-The primary CPU initializes the Non-Secure context for the secondary CPU while
-restoring re-entry information for the Non-Secure world.
-It initialises via ``cm_init_context_by_index(target_idx, ep )``.
+The primary CPU writes the entrypoint for the secondary CPU. When the secondary
+wakes up it initialises its own context via ``cm_init_my_context( ep )`` using
+the provided entrypoint.
``psci_warmboot_entrypoint()`` is the warm boot entrypoint procedure.
During the warm bootup process, secondary CPUs have their secure context