Tracking issue for porting multikernel to arm64.
Evaluation summary
On x86, arch/x86/multikernel/ (~2,800 lines) is almost entirely a software CPU lifecycle: relocate/secondary trampolines, an MMU-on park loop with private GDT/IDT, identity page tables, head_64.S scrubbing inherited CR4/EFER/GS state, and the repark/confirm-parked bookkeeping. It exists because x86 has no firmware-mediated CPU control after boot, and it is where the hardest bugs have lived.
On arm64 EL3 firmware owns CPU state through PSCI, and Linux already wraps it (cpu_psci_ops):
- The pool is the PSCI OFF state: a parked CPU executes nothing.
- The boot trampoline is
CPU_ON(mpidr, entry, dtb): it produces exactly the entry state head.S requires. No arm64 direct_boot.S, no head_64.S.
- Spawn secondaries come up through stock
cpu_psci_cpu_boot(); halt returns them with cpu_off(); confirm-parked is AFFINITY_INFO == OFF.
- Timer calibration handoff disappears (
CNTFRQ_EL0 is firmware-set, CNTPCT is global).
The difficulty moves to the interrupt controller: GICv3 has one distributor (stock gic_dist_init() would reset host SPIs) and one ITS command queue per ITS (a spawn cannot map its own MSIs). Those two, plus synthesizing the instance DTB on ACPI hosts, are the bulk of the work and the only places a port can break the host.
Tasks, in dependency order
Foundation
CPU lifecycle (small, low risk)
Boot data and messaging
Milestone A: device-less spawn boots on its own CPUs and memory, exchanges ring messages with the host, halts gracefully, re-spawns.
Interrupts (highest risk)
Milestone B: a PCIe device (virtio-pci on QEMU, NIC/NVMe on hardware) works in a spawn.
Robustness and isolation
Optional
Infrastructure
First target: QEMU virt with TF-A (secure=on,gic-version=3,its=on), then an SBSA server (Neoverse: PSCI + GICv3 + ITS + ECAM + TF-A/SDEI).
Tracking issue for porting multikernel to arm64.
Evaluation summary
On x86,
arch/x86/multikernel/(~2,800 lines) is almost entirely a software CPU lifecycle: relocate/secondary trampolines, an MMU-on park loop with private GDT/IDT, identity page tables,head_64.Sscrubbing inherited CR4/EFER/GS state, and the repark/confirm-parked bookkeeping. It exists because x86 has no firmware-mediated CPU control after boot, and it is where the hardest bugs have lived.On arm64 EL3 firmware owns CPU state through PSCI, and Linux already wraps it (
cpu_psci_ops):CPU_ON(mpidr, entry, dtb): it produces exactly the entry statehead.Srequires. No arm64direct_boot.S, nohead_64.S.cpu_psci_cpu_boot(); halt returns them withcpu_off(); confirm-parked isAFFINITY_INFO == OFF.CNTFRQ_EL0is firmware-set,CNTPCTis global).The difficulty moves to the interrupt controller: GICv3 has one distributor (stock
gic_dist_init()would reset host SPIs) and one ITS command queue per ITS (a spawn cannot map its own MSIs). Those two, plus synthesizing the instance DTB on ACPI hosts, are the bulk of the work and the only places a port can break the host.Tasks, in dependency order
Foundation
asm/multikernel.h, arch stubs (links withCONFIG_MULTIKERNEL=y)CPU lifecycle (small, low risk)
CPU_OFFevery CPUKEXEC_TYPE_MULTIKERNELImage loader + PoC cleaningBoot data and messaging
Milestone A: device-less spawn boots on its own CPUs and memory, exchanges ring messages with the host, halts gracefully, re-spawns.
Interrupts (highest risk)
Milestone B: a PCIe device (virtio-pci on QEMU, NIC/NVMe on hardware) works in a spawn.
Robustness and isolation
Optional
Infrastructure
First target: QEMU
virtwith TF-A (secure=on,gic-version=3,its=on), then an SBSA server (Neoverse: PSCI + GICv3 + ITS + ECAM + TF-A/SDEI).