riscv: fence.i entry stub to avoid stale I-cache on re-spawn

[congwang-mk]

Part of the RISC-V port. Must land together with the HSM spawn issue; a re-spawn without it fails intermittently.

RISC-V has no remote I-cache invalidation, _start_kernel executes fence.i only under CONFIG_RISCV_M_MODE, and OpenSBI does not invalidate caches on HART_START. A hart that ran instance A's image, called HART_STOP, and is later started into a new image at the same physical addresses can execute stale I-cache lines. The host cannot SBI_RFENCE_REMOTE_FENCE_I a STOPPED hart.

• Add a constant entry stub in the host-owned ctrl block, written once when the instance is created and never modified afterwards (so its own lines cannot be stale):

  fence.i
  ld   t0, entry(pc-relative)   # or pass entry in the opaque record
  jr   t0                       # a0 = hartid, a1 = dtb preserved
  

  If the entry address must change between spawns (re-exec with a different image size), read it from a data word written by the host with a fence before HART_START; data reads are coherent, only instruction fetch is the problem.
• mk_arch_spawn_instance() passes stub_pa to HART_START; the stub is the only piece of multikernel assembly on RISC-V.
• Document in Documentation/multikernel/ why the stub exists so nobody "simplifies" it away.

Test: spawn, halt, load a different image (different size/content) at the same grant, spawn again, repeat 50 times.

[pro-utkarshM]

i’m taking this as part of the #23-#26 RISC-V lifecycle and loader series. i’ll coordinate with @nickolaev and stack the work on #22 once the architecture foundation is available.