docs/components/context-management-library.rst

14 are not banked per world. When moving between the security states it is the
33 security states (Non-Secure, Secure, Realm). Each world must have its
46 In general, an ideal trusted system should have Secure world-specific configurations
48 need to maintain world-specific context to ensure that register entries from one
49 world do not leak or impact the execution of the CPU in other worlds.
57 for maintaining world-specific context essential for a trusted system.
65 two-world system, comprising of Non-Secure and Secure Worlds. In this case, the
86 Each world (Non-Secure, Secure, and Realm) should have their separate component
87 in EL3 responsible for their respective world context management.
88 Both the Secure and Realm world have associated dispatcher components in EL3
89 firmware to allow management of the respective worlds. For the Non-Secure world,
91 initialize the Non-Secure world context.
243 per-CPU and per-world to accurately represent asymmetric
283 CPUs maintain their context per world. The individual context memory allocation
284 for each CPU per world is allocated by the world-specific dispatcher components
291 It's important to note that the Normal world doesn't possess the dispatcher
293 handles memory allocation for ``Non-Secure`` world context for all CPUs.
302 world context of all CPUs.
310 Realm World dispatcher (RMMD) at EL3 allocates the memory for ``Realm`` world
317 To summarize, the world-specific context structures are synchronized with
338 allocated world-specific context memory.
341 of a Secure world image at S-EL2. If detected, it invokes the secure context
344 to the normal world, the Non-Secure context gets initialized via the context
346 and the CPU exits EL3 to enter the Normal world.
401 context for each world (Non-Secure, Secure and Realm).
407 world-specific context setup APIs.
414 world-specific context setup handlers listed above will be invoked once per-CPU
432 These functions are utilized by the world-specific dispatcher components running
434 during a world switch.
442 These functions are utilized by the world-specific dispatcher components running
444 during a world switch.
449 Pointer Authentication feature is enabled by default for Non-Secure world and
451 save and restore the Pauth registers during world switch.
482   the respective world's setup_context to select behaviour.
501 Per-world Context
507 The Per-world context structure is intended for managing EL3 system registers with
509 individual world. This structure operates independently of the CPU context
524 that caches architectural ID registers common across all CPUs in a world.
528 During initialization, the per-world ID register cache is populated by
541 with the values of the incoming world. This implies that if the CPU is entering
542 EL3 from NS world, the EL1 and EL2 system registers which might be modified in
545 world, written during the previous ERET from EL3 to NS(EL2/EL1).
550 world (Secure/Non-Secure/Realm). This becomes problematic in scenarios where the
551 EL3/Root world must explicitly use architectural features that depend on system
553 A good example of this is the PAuth regs. The Root world would need to program
555 to EL3 from any world.
556 Therefore, Root world should maintain its own distinct settings to access
571 The figure below illustrates the same with NS-world as a reference while entering