riscv: implement multikernel lifecycle and safe shutdown

[pro-utkarshM]

Summary

• implement the RISC-V multikernel CPU lifecycle with direct SBI HSM calls,
  physical hart IDs, bounded HART_STATUS polling, and parked-state checks
• add an immutable entry stub that executes fence.i on every start while
  preserving the RISC-V a0/a1 boot ABI
• contain spawn halt, power-off, reboot, panic, and SMP-stop paths with
  HART_STOP, and serialize lifecycle/resource changes against image teardown
• retain a hot-added CPU with its instance when a lost ACK leaves ownership
  uncertain, so a possibly running hart is never exposed through the free pool

Addresses #23, #24, and #25.

Base and attribution

This draft targets multikernel-riscv at
fe31d7b0ca32b0f806c88059c88d70600fda45cc, the RISC-V foundation from #37
that Cong applied for follow-up work.

The previous temporary replay of Nikolay Nikolaev's foundation commit has been
dropped. His accepted foundation remains below this series with its original
authorship; every commit in this PR is above that branch point.

Scope

This PR keeps #23-#25 together because lifecycle, entry-cache coherency, and
safe shutdown share the same HSM handoff invariants.

#26 remains a separate follow-up branch. RISC-V instance-DTB device filtering
(#27) and firmware IPI receive support (#28) are out of scope.

Validation

Current head: eef3dcbad234

• rv64 LLVM vmlinux Image build with CONFIG_MULTIKERNEL=y
• rv64 LLVM vmlinux Image build with multikernel disabled
• nommu_virt_defconfig check proving RISCV_M_MODE=y excludes multikernel
• x86_64 GCC vmlinux build with CONFIG_MULTIKERNEL=y, CONFIG_OF=y, and
  CONFIG_KEXEC_FILE=y
• linked-symbol check for every RISC-V multikernel architecture hook
• entry-stub disassembly check: leading fence.i, no a0/a1 clobber, and no
  relocations
• git diff --check and strict per-commit checkpatch.pl: zero reported
  errors, warnings, or checks
• focused source-order assertions for reserve-before-handoff, uncertain-CPU
  accounting, RISC-V stopped-state confirmation, and halted-settlement locking

Prior QEMU/OpenSBI runtime results were produced on the pre-rebase series
stacked with #26. The accepted-base head still needs runtime revalidation
before this draft is ready for merge.

Remaining draft gates

• rebase the separate riscv: KEXEC_TYPE_MULTIKERNEL Image loader, placement in the grant, no purgatory #26 loader branch onto this head
• rerun QEMU virt + OpenSBI PLIC lifecycle tests on the accepted base
• rerun halt, power-off, reboot, panic, secondary-hart stop, same-address
  respawn, different-Image respawn, and 50-cycle stress tests
• inject lost CPU-add ACK and partial-start failures and verify conservative
  ownership/cleanup behavior

AIA runtime validation remains blocked on #27's per-hart IMSIC/APLIC and device
filtering. MKTTY/ring validation remains blocked on #28; neither is duplicated
here.

[pro-utkarshM]

@congwang-mk, before updating this draft, could you confirm the dependency ordering?

We have newer local #23–#25 lifecycle commits, with #26 kept as a separate follow-up. Standalone builds passed; QEMU PLIC/AIA validation passed on an integration stack with explicit runtime dependencies, including 50-cycle same-Image and alternating-Image re-spawns.

The tested stack still has the shared receive-ring reset limitation. Nickolaev’s #7 overlaps that work but is not integrated or validated in our stack. Should we depend on #7 first, or submit the bounded RISC-V series with that limitation disclosed?

Which public #27/#28 commits should we use instead of our temporary attributed runtime extracts?

[congwang-mk]

There are no public #27/#28 commits: both are unassigned with no PR or branch, and multikernel-riscv has only Nikolay's #22 skeleton (fe31d7b), nothing for #27/#28.

Please don't carry extracts from Nikolay's July riscv branch. It predates the device tree rework, where the manifest became the spawn's boot tree, so #27 is now "pass the manifest as a1 and add hart/intc nodes to mk_dt_emit_boot_tree()". #27 and #28 are open to claim as separate PRs on multikernel-riscv. Publish your integration stack as a test-only branch so the results are reproducible.

Don't depend on #7; disclose the ring-reset limitation.

For this PR:

1. Emit the entry stub from mk_manifest_chosen() via an arch hook, under /chosen with the multikernel, prefix, not by reopening the finalized FDT with PAGE_SIZE. The manifest is 256 KB on this base, so any boot tree larger than one page fails there.
2. Move the SBI IPI send and mk_panic_to_pool() to riscv: multikernel doorbell (IMSIC identity or SBI IPI convention) #28, and send multikernel,host-ipi-cpu to master separately with a CPU 0 fallback, so a new spawn kernel still boots on an older host.
3. Split the kexec-lock serialization, the hot-add retention and the spawn-state changes into a PR against master, tested on x86, and don't use kexec_trylock() as the resource lock. mk_overlay_mutex already serializes resource changes; image teardown and exec should take the multikernel lock, not the other way round.
4. Explain in the commit why the prime handshake is needed versus the opaque-record stub from riscv: fence.i entry stub to avoid stale I-cache on re-spawn #24.