Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AArch64: Add direct kernel boot support #297

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jongwu
Copy link
Contributor

@jongwu jongwu commented Nov 23, 2023

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;

Add a utility function to retrive the info from FDT. It's VMM's
responsibility to store kernel info inside FDT Chosen node then we can
get it there.

Signed-off-by: Jianyong Wu <[email protected]>
Add kernel image loader and try to find kernel image info in FDT, if
there is one, load and start kernel directly.

Signed-off-by: Jianyong Wu <[email protected]>
Reserved 64M for payload to hold kernel image. So, bump ram_min to 0x44400000

Signed-off-by: Jianyong Wu <[email protected]>
cmdline is essential for direct kernel boot. To pass cmdline:
1. get original cmdline from FDT;
2. allocate memory for it;
3. convert raw cmdline from utf-8 to utf-16;
4. put cmdline info into image handle;

Signed-off-by: Jianyong Wu <[email protected]>
@retrage
Copy link
Contributor

retrage commented Dec 7, 2023

@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
Copy link
Contributor Author

jongwu commented Dec 8, 2023

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.

@rbradford
Copy link
Member

@retrage Do you have any interest in this PR?

@retrage
Copy link
Contributor

retrage commented Oct 17, 2024

@rbradford I still don't understand the motivation, but it's worth to merge to the main branch if Confidential Computing really needs this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants