openvmm: support launching UEFI from IGVM#3726
Conversation
Add an explicit typed IGVM CLI form for UEFI payloads:
--igvm type=uefi,path=/path/to/file.bin
This lets OpenVMM distinguish UEFI IGVM payloads from the legacy generic IGVM
path, while preserving existing --igvm FILE behavior.
UEFI boot requires OpenVMM to provide the firmware config blob that is already
used by direct --uefi boot. Reuse that config blob construction for UEFI IGVM
launches, write it to CONFIG_BLOB_GPA_BASE, and on x64 pass that GPA in R12
when the IGVM did not already provide R12.
Make typed UEFI IGVMs imply the fixed-address/file-address IGVM path and reject
incompatible explicit relocation settings. Also add the non-isolated x64 UEFI
guest config to the UEFI IGVM manifest.
This is an incremental step toward using OpenVMM to launch IGVM-packaged test
payloads, which is needed for the CCA OpenHCL bring-up path.
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds support for a “UEFI helper” IGVM path, including CLI parsing/validation and runtime patching of the UEFI config blob when loading an IGVM.
Changes:
- Extend
--igvmCLI to accepttype=uefi,path=...and validate related option combinations. - Add an
uefiflag toLoadMode::Igvmand patch the UEFI config blob + register state whenuefi=true. - Refactor UEFI loader to expose a reusable
build_config_blobhelper; update UEFI x64 manifest to include an IGVM config.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| vm/loader/manifests/uefi-x64.json | Adds an IGVM-based UEFI guest config entry. |
| openvmm/openvmm_entry/src/lib.rs | Wires new IGVM CLI structure into config building and load mode selection. |
| openvmm/openvmm_entry/src/cli_args.rs | Introduces IgvmCli, updates flags, and adds parsing tests + validation hook. |
| openvmm/openvmm_defs/src/config.rs | Extends LoadMode::Igvm with a uefi boolean. |
| openvmm/openvmm_core/src/worker/vm_loaders/uefi.rs | Refactors to expose build_config_blob for reuse. |
| openvmm/openvmm_core/src/worker/dispatch.rs | Enables UEFI dependencies for IGVM(UEFI) and patches config blob into guest memory. |
| let mut entropy = [0; 64]; | ||
| getrandom::fill(&mut entropy).expect("rng failure"); |
smalis-msft
left a comment
smalis-msft
left a comment
There was a problem hiding this comment.
Maybe this is a question for @chris-oo, but is this really something that needs to be specified by the user? We can't determine it from the IGVM file alone?
|
If this is something we want to support long term we should probably add a VMM test or two for it too. |
I investigated this as well, but there doesn't seem to be a simple or clean way to determine whether the content inside an IGVM is UEFI. |
|
Yes, the IGVM file does not tell you what the shape of host configuration should be. So we need a hint/configuration lever to effectively say "this is the set of devices/config you should use" along with "here is the igvm file you should boot". This is also required once we support IGVM based boot for CCA/SNP in openvmm, for the same reasons. If we are booting a linux direct IGVM file, we'd want a linux direct chipset, versus if we boot an enlightened UEFI, versus an OpenHCL IGVM image. |
chris-oo
left a comment
chris-oo
left a comment
There was a problem hiding this comment.
I think this seems reasonable, but in some ways I think "load mode IGVM" needs to be able to specify more/different levers. In some ways, we may want to allow load mode igvm to be the same as some other config like uefi/pcat/etc, and perhaps the current mode should be renamed to OpenHCL load mode which only loads from IGVM.
But I don't think we need to do this refactor now.
|
Alright if we want to punt on that let's at least add a VMM test for this flow. |
Sure, let me explore how to add a test |
This PR adds support for launching UEFI packaged inside an IGVM file, starting
with the x64 non-isolated UEFI IGVM case.
The broader goal is to enable launching CCA OpenHCL. To get there, OpenVMM needs
to be usable as the VM manager inside the paravisor. As a first step, we are
moving from the current tmk_vmm + simple_tmk flow toward an openvmm + equivalent
simple_test flow, where the test payload is packaged as an IGVM.
While investigating that path, we found that OpenVMM does not yet have complete
AArch64 IGVM loader support. Before implementing and validating that path, we
wanted a simple existing IGVM payload to use as test input. UEFI packaged inside
IGVM was a good candidate because the repo already has build configuration for
it.
However, launching UEFI from IGVM did not work even on x64. OpenVMM could
directly boot UEFI via --uefi, and it could load IGVM files, but the IGVM path
did not provide the UEFI-specific helper/configuration flow that UEFI firmware
expects. This PR fixes that gap as an incremental step toward the larger
CCA/OpenHCL bring-up.
UEFI boot in OpenVMM depends on a UEFI configuration blob built by the VMM. That
blob carries firmware-facing configuration such as ACPI tables, MMIO ranges,
memory map, processor information, entropy, firmware flags, and other platform
data.
The direct --uefi path already builds and passes this blob to UEFI. However, when
UEFI is packaged into an IGVM, the generic --igvm path did not know that the IGVM
payload was UEFI and therefore did not provide the UEFI config blob/helper
behavior.
This meant there was no supported way to launch a UEFI IGVM even on x64.
Therefore, we have the following changes:
UEFI IGVM case.
launch.
provide that register.
config.
The legacy --igvm FILE behavior remains unchanged so existing IGVM users are
not affected.
The new type=uefi,path=... form gives OpenVMM an explicit signal that the IGVM
payload is UEFI and needs UEFI-specific setup. This avoids guessing based on
relocation mode or file contents, and leaves room for other typed IGVM payloads
in the future.
Manually tested the x64 UEFI IGVM launch path and verified that it reaches the
same expected UEFI behavior as direct --uefi boot.
The UEFI IGVM is built by:
cargo xflowey build-igvm x64 --override-manifest=vm/loader/manifests/uefi-x64.json
The test command is: (on WSL2)
sudo ./target/debug/openvmm --igvm type=uefi,path=
OPENVMM_ROOT/flowey-out/artifacts/build-igvm/debug/uefi-x64-custom/openhcl-uefi-x64-custom.bin
-m 2GB -p 1