Part of the arm64 port.
On arm64 the pool is the PSCI OFF state and the boot trampoline is CPU_ON itself: CPU_ON(mpidr, entry_pa, dtb_pa) produces exactly the entry state arch/arm64/kernel/head.S requires (MMU off, x0 = DTB). No direct_boot.S, no head_64.S, no identity page tables.
Implement in arch/arm64/multikernel/spawn.c:
- mk_arch_spawn_instance(image, instance, cpu): clean the Image segments, DTB and ctrl block to PoC (dcache_clean_poc, as kexec_segment_flush() does), then psci_ops.cpu_on(cpu_logical_map(cpu), image->start, image->arch.dtb_mem). Keep the mk_spawn_context concept only as the host-side record (ctrl block, DTB address); it is no longer a mailbox.
- mk_arch_release_instance(): free the record; nothing is parked anywhere.
- mk_arch_confirm_parked(instance, mpidr): psci_ops.affinity_info(mpidr, 0) == PSCI_0_2_AFFINITY_LEVEL_OFF, with the same 100 ms poll cpu_psci_cpu_kill() uses.
- mk_repark_cpu_to_instance() / mk_repark_cpu_to_host() / mk_repark_instance_to_host(): no-ops returning 0 (an OFF CPU belongs to whoever calls CPU_ON next).
- mk_arch_register_cpu(): nothing beyond the DTB /cpus entry (see DTB issue).
- Host side multikernel_play_dead() equivalent: pool CPUs go through the stock cpu_psci_cpu_die(); only cpu_psci_cpu_can_disable() (Trusted OS resident) can refuse, surface that as "CPU cannot be pooled".
Notes:
- Entry EL follows the platform (TF-A enters at EL2 if SCR_EL3.HCE is set), so a spawn can run KVM.
- Any kernel can CPU_ON any OFF MPIDR; ownership stays a host bookkeeping matter, same trust model as INIT/SIPI on x86.
Reactions are currently unavailable
Part of the arm64 port.
On arm64 the pool is the PSCI OFF state and the boot trampoline is CPU_ON itself: CPU_ON(mpidr, entry_pa, dtb_pa) produces exactly the entry state arch/arm64/kernel/head.S requires (MMU off, x0 = DTB). No direct_boot.S, no head_64.S, no identity page tables.
Implement in arch/arm64/multikernel/spawn.c:
Notes: