Skip to content

riscv: KEXEC_TYPE_MULTIKERNEL Image loader, placement in the grant, no purgatory #26

Open

Description

@congwang-mk

Part of the RISC-V port.

arch/riscv/kernel/kexec_image.c already loads the Image format at any 2 MB-aligned physical address (kernel VA is fixed, PA is free, kernel_map.va_pa_offset computed at runtime). machine_kexec_file.c always loads purgatory and jumps through it.

  • Add KEXEC_TYPE_MULTIKERNEL handling: place Image and instance DTB inside the grant (instance->memory_regions), never in the running kernel's memory; skip purgatory (kexec_load_purgatory(), riscv_kernel_entry symbol patching).
  • image->start = Image load address (_start is offset 0); image->arch.fdt_addr = instance DTB. These feed the fence.i stub.
  • Never call machine_kexec()/riscv_kexec_relocate paths; the current kernel keeps running.
  • No PoC cleaning needed (harts are coherent), but execute fence after writing the image/DTB/ctrl block so the stores are ordered before HART_START.
  • Regenerate the DTB /memory nodes on every exec, not at load (the grant can change between load and exec; see the x86 "grant shortfall" fix).

Activity

  1. pro-utkarshM commented on Aug 26, 2026

    @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.

  2. pro-utkarshM commented on Nov 3, 2026

    @pro-utkarshM

    The refreshed #26 follow-up is published separately at
    riscv/image-loader-submit-v44,
    tip ec098e55e2a3799329918236033a0882cd561779.

    It remains one loader commit above the refreshed #23-#25 lifecycle stack and
    keeps multikernel Image placement inside the grant with no purgatory execution
    path. The exact tip completed a cold rv64 LLVM vmlinux + Image link; Image
    parser (14 checks) and prepare fixtures passed. Preserved QEMU evidence covers
    load rejection/retry plus manifest/grant/placement failure and retry on Sv39
    and Sv48.

    I am not folding this into PR #39 or the ordinary/crash-kexec purgatory fix in
    PR #43. I am also leaving the older experimental #26 branches intact. A
    separate loader PR can be opened once the #39 prerequisite/review shape is
    accepted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    riscvriscv port

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions