Lines Matching full:world

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
47 that are not influenced by Normal World operations. Therefore, for each CPU, we
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
66 EL3 Firmware is assumed to be running in Secure World.
70 state called root. EL3 firmware now runs at Root World and thereby is
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.
268 CPUs maintain their context per world. The individual context memory allocation
269 for each CPU per world is allocated by the world-specific dispatcher components
276 It's important to note that the Normal world doesn't possess the dispatcher
278 handles memory allocation for ``Non-Secure`` world context for all CPUs.
286 Secure World dispatcher (such as SPMD) at EL3 allocates the memory for ``Secure``
287 world context of all CPUs.
295 Realm World dispatcher (RMMD) at EL3 allocates the memory for ``Realm`` world
302 To summarize, the world-specific context structures are synchronized with
323 allocated world-specific context memory.
326 of a Secure world image at S-EL2. If detected, it invokes the secure context
329 to the normal world, the Non-Secure context gets initialized via the context
331 and the CPU exits EL3 to enter the Normal world.
349 restoring re-entry information for the Non-Secure world.
386 context for each world (Non-Secure, Secure and Realm).
392 world-specific context setup APIs.
399 world-specific context setup handlers listed above will be invoked once per-CPU
417 These functions are utilized by the world-specific dispatcher components running
419 during a world switch.
427 These functions are utilized by the world-specific dispatcher components running
429 during a world switch.
434 Pointer Authentication feature is enabled by default for Non-Secure world and
436 save and restore the Pauth registers during world switch.
467   the respective world's setup_context to select behaviour.
486 Per-world Context
492 The Per-world context structure is intended for managing EL3 system registers with
494 individual world. This structure operates independently of the CPU context
515 with the values of the incoming world. This implies that if the CPU is entering
516 EL3 from NS world, the EL1 and EL2 system registers which might be modified in
519 world, written during the previous ERET from EL3 to NS(EL2/EL1).
524 world (Secure/Non-Secure/Realm). This becomes problematic in scenarios where the
525 EL3/Root world must explicitly use architectural features that depend on system
527 A good example of this is the PAuth regs. The Root world would need to program
529 to EL3 from any world.
530 Therefore, Root world should maintain its own distinct settings to access
545 The figure below illustrates the same with NS-world as a reference while entering