cloud-hypervisor / rust-hypervisor-firmware

Apache License 2.0
581 stars 53 forks source link

AArch64: Add direct kernel boot support #297

Open jongwu opened 7 months ago

jongwu commented 7 months ago

Direct kernel boot, that load and start kernel specified by kernel cmdline, is an important feature in some scenairo like secure containers, confidential container.

How does it work?

  1. Specify kernel image and firmware from VM cmdline; (user)
  2. Load kernel image somewhere inside memory and store kernel info (including kernel location and size) inside FDT/Chosen; (VMM does)
  3. When firmware boot, retrive kernel info from FDT/Chosen; (RF)
  4. Load kernel to kernel start address; (RF)
  5. Prepare kernel cmdline;(RF)
  6. Start kernel;(RF)

Dependency: CH lacks of support for this feature;

retrage commented 6 months ago

@jongwu I do not understand why direct boot is needed. When a kernel image is specified by VMM arguments, the image is loaded directly into the guest memory and sets up the guest state as described in the document. This way, no firmware (RHF, EDK2) is required. Please clarify the motivation for this feature.

jongwu commented 6 months ago

Hi @retrage -,

UEFI based direct kernel boot means that starts firmware first and load kernel instead of bootloader when firmware transfers control at the so-called BDS(Boot Device Selection) phase. We need firmware because we need ACPI and also we want to start kernel specified by command line not from disk.

We can get some benifits from this feature:

  1. Start disk image with just rootfs in it, that'say without kernel/bootloader. It's the way in kata containers boot that there is just a rootfs inside kata disk image and start kernel specified in command line while start kata guest from firmware;
  2. Pass kernel flexibly easily through command line without subtitute kernel inside disk while boot from firmware;
  3. It speeds up boot time as for skipping bootloader;
  4. The current Confidential Computing implementation relys on this feature;

With this feature, we can deploy RHF more widely such as into kata and confidential computing containers.