feat: add initramfs loading support for all architectures

[YZYY95K]

Overview

Add initramfs loading support to hvisor-tool, enabling zones to load initramfs images via the HVISOR_LOAD_IMAGE ioctl, similar to how kernel and DTB images are currently loaded.

Changes

tools/hvisor.c

Added initramfs_filepath and initramfs_load_paddr JSON field parsing in zone_start_from_json(). When both fields are present, the initramfs image is loaded to the specified physical address using the existing load_image_to_memory() function (which calls HVISOR_LOAD_IMAGE ioctl).

Key Design Decisions

1. Architecture-independent: The initramfs loading is not in arch_config but at the top level of the JSON config, making it work for all architectures (ARM64, RISC-V, x86_64, LoongArch64).

2. No struct changes: No changes to zone_config_t or CONFIG_MAGIC_VERSION. The initramfs is loaded separately to memory, and the guest discovers it via the DTB chosen node (linux,initrd-start/linux,initrd-end).

3. Inspired by x86_64: The x86_64 architecture already has initrd loading in arch_config. This PR makes the feature available to all architectures.

Usage

Add the following fields to your zone JSON config:

{
    "kernel_filepath": "./asterinas.bin",
    "dtb_filepath": "./zone1.dtb",
    "initramfs_filepath": "./initramfs.cpio.gz",
    "initramfs_load_paddr": "0x87e00000",
    "kernel_load_paddr": "0x84000000",
    "dtb_load_paddr": "0x83000000",
    "entry_point": "0x84000000"
}

Testing

The initramfs loading has been tested with Asterinas OS as zone1 on hvisor RISC-V (qemu-plic). The initramfs was successfully loaded to memory and the guest OS was able to access it via the DTB chosen node.

Related

• hvisor PR: feat(riscv64): support Asterinas OS as guest on hvisor hvisor#325
• This enables hvisor-tool to load all zone1 images (kernel, dtb, initramfs) without needing QEMU -device loader parameters.

[agicy]

Thank you for this contribution! I took a close look at the existing code, and I believe the current modules mechanism already covers the initramfs use case without introducing a dedicated top-level field.

The modules array (parsed by parse_modules) already allows loading arbitrary files to specified physical addresses via name, filepath, and load_paddr. Loading an initramfs can be done like this:

"modules": [
  {
    "name": "initramfs",
    "filepath": "./initramfs.cpio.gz",
    "load_paddr": "0x87e00000"
  }
]

This approach is more flexible - you can load multiple initramfs images or other firmware files - and it avoids adding redundant configuration keys that might confuse users about which method to use.

I'd suggest closing this PR and, if needed, documenting or adding an example showing how to load an initramfs via modules.

On a related note, I think we might also consider moving dtb_filepath and dtb_load_paddr into modules in the future, since x86 doesn't use a DTB and having it at the top level ties a somewhat architecture-specific concept to the zone config. But that can be a separate discussion.

Thanks again for your interest in improving hvisor, and I hope this feedback is helpful!

[YZYY95K]

Thank you for the detailed review! You're absolutely right - the modules mechanism already covers this use case perfectly. I wasn't aware of it when I submitted this PR.

I'll close this PR and update the hvisor-side configuration to use modules instead:

"modules": [
    {
        "name": "initramfs",
        "filepath": "./initramfs.cpio.gz",
        "load_paddr": "0x87e00000"
    }
]

The suggestion to eventually move dtb_filepath and dtb_load_paddr into modules also makes sense - that would be a cleaner, more uniform approach.

Thanks again for the guidance!

[YZYY95K]

Thank you for the review! You're absolutely right - the existing modules mechanism already covers this use case perfectly. I'll close this PR and use the modules array to load initramfs instead.

Example usage:

"modules": [
  {
    "name": "initramfs",
    "filepath": "./initramfs.cpio.gz",
    "load_paddr": "0x87e00000"
  }
]

Thanks for the guidance!