openvmm: support aarch64 UEFI without Hyper-V hypervisor enlightenments

[Chris Oo (chris-oo)]

We added support in UEFI to not expose hv enlightenments, but did not plumb thru the value when --no-hv was specified. Pass this info to UEFI, and add new vmm_tests to test this.

[Jocelyn Berrendonner [MSFT] (JocelynBerrendonner)]

LGTM

[Copilot]

Pull request overview

This PR completes the plumbing for AArch64 UEFI boots that intentionally do not expose Hyper-V (HV#1) enlightenments (e.g., when --no-hv is specified), ensuring the loader communicates the correct SEC platform type to firmware and adding an integration test to validate guests don’t detect Hyper-V.

Changes:

• Add --no-hv CLI support (requires --no-vmbus, rejects x86_64 UEFI) and propagate the intent through OpenVMM config/state.
• Extend the UEFI loader interface to accept hv_enabled; on AArch64 pass a generic vs Hyper-V SEC platform type via x2 (and explicitly reject x86_64 UEFI without HV).
• Update Petri to propagate no_hv, support multiple NVMe namespaces per controller/port, and add a new AArch64 UEFI no-hv vmm_test.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
vmm_tests/vmm_tests/tests/tests/multiarch.rs	Adds an AArch64 UEFI --no-hv boot test and guest-side verification that Hyper-V is not detected.
vm/loader/src/uefi/mod.rs	Threads hv_enabled into arch-specific UEFI loaders; sets AArch64 SEC platform type in x2; rejects x86_64 UEFI without HV.
vm/loader/loader_defs/src/uefi.rs	Introduces SecPlatformType open enum for firmware SEC platform selection.
vm/loader/loader_defs/src/lib.rs	Exposes the new uefi loader defs module.
vm/loader/igvmfilegen/src/main.rs	Updates IGVM generator to call the new UEFI loader signature (HV enabled).
petri/src/vm/openvmm/construct.rs	Propagates no_hv and groups NVMe drives into controllers with multiple namespaces per port.
petri/src/vm/mod.rs	Adds no_hv plumbing to Petri builder/properties and improves NVMe agent-disk placement when no_vmbus.
openvmm/openvmm_entry/src/ttrpc/mod.rs	Populates the new UEFI config field (enable_hv) for the ttrpc path (currently fixed true).
openvmm/openvmm_entry/src/lib.rs	Implements --no-hv behavior for UEFI and plumbs it into load mode and UEFI settings.
openvmm/openvmm_entry/src/cli_args.rs	Adds the --no-hv clap option plus parsing tests and help text.
openvmm/openvmm_defs/src/config.rs	Extends LoadMode::Uefi with enable_hv (MeshPayload).
openvmm/openvmm_core/src/worker/vm_loaders/uefi.rs	Passes hv through to the loader so firmware gets the correct SEC platform type.
openvmm/openvmm_core/src/worker/dispatch.rs	Threads enable_hv into UefiLoadSettings used during firmware load.
Guide/src/reference/openvmm/management/cli.md	Documents the new --no-hv flag and its constraints.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

Suppressed comments (3)

openvmm/openvmm_entry/src/cli_args.rs:4842

• If --no-hv is made to require --uefi, this unit test needs to include --uefi in the successful parse case (and in the conflicting --hv case). Otherwise the test will start failing once the clap requirement is tightened.

    fn test_no_hv_requires_no_vmbus() {
        assert!(Options::try_parse_from(["openvmm", "--no-hv"]).is_err());

        let opt = Options::try_parse_from(["openvmm", "--no-hv", "--no-vmbus"]).unwrap();
        assert!(opt.no_hv);

openvmm/openvmm_entry/src/cli_args.rs:285

• --no-hv is documented and implemented as a UEFI-only mode, but the clap definition does not require --uefi. As-is, openvmm --no-hv --no-vmbus will parse successfully and then --no-hv is silently ignored in the Linux-direct path (and other non-UEFI paths), which is surprising CLI behavior. Require uefi (and optionally conflict with igvm) at the argument level so misuse is rejected up front.

This issue also appears on line 4838 of the same file.

    /// Boot UEFI without exposing hypervisor (HV#1) enlightenments. Requires
    /// `--no-vmbus` since VMBus depends on the hypervisor.
    #[clap(long, requires("no_vmbus"), conflicts_with_all = ["hv", "vtl2", "get", "pcat"])]
    pub no_hv: bool,

petri/src/vm/openvmm/construct.rs:968

• with_no_hv() is documented as unsupported on x86_64 UEFI, but Petri currently still allows generating an x86_64 UEFI LoadMode::Uefi { enable_hv: false }, which will later fail in the loader (HvRequired) with a less direct error. Consider rejecting this configuration in Petri when building the UEFI load mode so the failure is immediate and explicit.

                    enable_vmbus: !self.no_vmbus,
                    force_dma_bounce: *force_dma_bounce,
                    enable_hv: !self.no_hv,

[github-actions]

5 Petri tests failed (0 unstable)

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

Suppressed comments (3)

openvmm/openvmm_entry/src/cli_args.rs:284

• The --no-hv CLI help text doesn’t mention that it’s unsupported on x86_64 UEFI, even though it will fail at runtime there. Documenting this constraint in the flag help avoids surprising users.

    /// Boot UEFI without exposing hypervisor (HV#1) enlightenments. Requires
    /// `--no-vmbus` since VMBus depends on the hypervisor.
    #[clap(

vmm_tests/vmm_tests/tests/tests/multiarch.rs:22

• size_of is imported unconditionally, but it’s only used inside a #[cfg(target_os = "linux")] test. On non-Linux builds this becomes an unused import and can fail builds if warnings are denied. Gate the import (or inline it) the same way as the test.

#[cfg(target_os = "linux")]
use petri_artifacts_vmm_test::artifacts::OPENVMM_VHOST_NATIVE;
use std::mem::size_of;
use vmm_test_macros::openvmm_test;

Guide/src/reference/openvmm/management/cli.md:57

• Docs for --no-hv say it conflicts with --hv, --vtl2, --get, and --pcat, but the CLI definition also declares a conflict with --igvm. Please update the Guide to match the actual CLI constraints.

* `--no-hv`: Boots AArch64 UEFI without exposing Hyper-V enlightenments.
  By default, UEFI exposes the enlightenments. This option requires
  `--no-vmbus`, is not supported for x86_64 UEFI, and conflicts with `--hv`,
  `--vtl2`, `--get`, and `--pcat`.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Guide/src/reference/openvmm/management/cli.md:57

• The CLI docs for --no-hv list conflicts with --hv, --vtl2, --get, and --pcat, but the actual clap definition also conflicts with --igvm (see conflicts_with_all = ["hv", "vtl2", "get", "pcat", "igvm"]). The Guide should mention --igvm too so users don’t assume it’s supported.

* `--no-hv`: Boots AArch64 UEFI without exposing Hyper-V enlightenments.
  By default, UEFI exposes the enlightenments. This option requires
  `--no-vmbus`, is not supported for x86_64 UEFI, and conflicts with `--hv`,
  `--vtl2`, `--get`, and `--pcat`.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Guide/src/reference/openvmm/management/cli.md:57

• The --no-hv help text doesn’t mention that it also conflicts with --igvm (the clap definition includes conflicts_with_all = ["hv", "vtl2", "get", "pcat", "igvm"]). This makes the Guide inconsistent with the actual CLI behavior.

* `--no-hv`: Boots AArch64 UEFI without exposing Hyper-V enlightenments.
  By default, UEFI exposes the enlightenments. This option requires
  `--no-vmbus`, is not supported for x86_64 UEFI, and conflicts with `--hv`,
  `--vtl2`, `--get`, and `--pcat`.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Guide/src/reference/openvmm/management/cli.md:57

• The Guide docs for --no-hv list conflicts, but they omit --igvm. In openvmm_entry the flag is declared with conflicts_with_all = ["hv", "vtl2", "get", "pcat", "igvm"], so the docs should match to avoid misleading CLI usage.

* `--no-hv`: Boots AArch64 UEFI without exposing Hyper-V enlightenments.
  By default, UEFI exposes the enlightenments. This option requires
  `--no-vmbus`, is not supported for x86_64 UEFI, and conflicts with `--hv`,
  `--vtl2`, `--get`, and `--pcat`.