openvmm, virt_kvm: add support for snp with linux direct boot

[chris-oo]

Add support for direct booting a enlightened Linux kernel on virt_kvm for SNP. This supports only virtio devices exposed over pcie, no hyper-v enlightenments or other devices.

Note that the kernel expects all RAM to be accpeted at kernel start. Since we directly launch the kernel without a boot shim, there is a hack to accept all memory on behalf of the guest, which is very slow. This could be fixed in the future by having a small boot shim to accept memory on behalf of the kernel.

[github-actions]

⚠️ Unsafe Code Detected

This PR modifies files containing unsafe Rust code. Extra scrutiny is required during review.

For more on why we check whole files, instead of just diffs, check out the Rustonomicon

[Copilot]

Pull request overview

Adds initial AMD SEV-SNP support for Linux direct boot on the virt_kvm backend, including guestmemfd-backed private memory, SNP launch measurement/import of initial pages, and CLI/config validation to keep the supported configuration surface small (virtio-over-PCIe only).

Changes:

• Introduces a new BaseChipsetType::EnlightenedLinuxDirect path intended for SNP Linux direct boot.
• Implements KVM SNP plumbing: /dev/sev init, initial page acceptance/launch update flow, and handling of KVM_HC_MAP_GPA_RANGE.
• Adds CLI/config validation and a loader-side “pre-accept all RAM” bring-up hack for SNP direct boot.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
vmm_core/vm_manifest_builder/src/lib.rs	Adds new chipset type and build path for “enlightened” Linux direct boot; adds missing PCI config port stubs.
vmm_core/virt_kvm/src/snp.rs	Implements SNP launch flow (launch start/update/finish) and page import handling.
vmm_core/virt_kvm/src/memory.rs	Adds KVM hypercall-backed memory attribute switching and private-range resolution helpers.
vmm_core/virt_kvm/src/lib.rs	Extends KvmError and KvmPartitionInner state to support SNP launch and SEV device tracking.
vmm_core/virt_kvm/src/arch/x86_64/snp.rs	Adds mapping from InitialPageImportType to SNP launch page types (with unit tests).
vmm_core/virt_kvm/src/arch/x86_64/mod.rs	Wires SNP isolation into KVM VM creation, guestmemfd backing, hypercall handling, and SEV termination reporting.
vmm_core/virt_kvm/Cargo.toml	Adds libc dependency and test_with_tracing dev-dependency.
openvmm/openvmm_entry/src/lib.rs	Selects the new chipset type for --isolation snp and validates SNP configs post-build.
openvmm/openvmm_entry/src/cli_args.rs	Exposes --isolation snp and adds CLI-side validation + tests for SNP option constraints.
openvmm/openvmm_core/src/worker/vm_loaders/linux.rs	Adds SNP-only logic to import/accept remaining RAM pages for direct boot (with unit test).
openvmm/openvmm_core/src/worker/dispatch.rs	Adds runtime validation gates for SNP guestmemfd limitations.
openvmm/openvmm_core/Cargo.toml	Adds test_with_tracing dev-dependency for new tests.
Cargo.lock	Locks new dependency additions (libc, test_with_tracing) where applicable.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 14 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

vmm_core/virt_kvm/src/snp.rs:108

• sev_snp_launch_update is invoked with gpa / HV_PAGE_SIZE and len = page.range.len() without validating that the range is 4K-aligned and a multiple of 4K. If a caller provides an unaligned range, we’ll compute the wrong PFN and/or pass an invalid length to KVM (and the existing UnalignedSnpLaunchRange error is never used).

            let gpa = page.range.start();
            tracing::trace!(
                gpa,
                len = page.range.len(),
                ?kvm_page_type,

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

vmm_core/virt_kvm/src/snp.rs:73

• SNP launch update assumes page GPA/length are 4KiB-aligned (e.g., gfn_start is computed via gpa / HV_PAGE_SIZE). Today there’s no explicit validation, and the UnalignedSnpLaunchRange error variant is never used. Add an early alignment/empty-range check so misaligned imports fail deterministically with a clear error instead of passing a truncated GFN into KVM.

        let memory = self.memory.lock();
        for page in pages {
            let kvm_page_type = crate::arch::snp::snp_launch_page_type(page.import_type)?;

            let private_range = private_memory_range_from_slots(page.range, &memory.ranges)

[smalis-msft]

What are these ports normally for, the pci bus? Why do we need them?

[chris-oo]

linux probes these ports if you have pci (very questionable in a cvm, yes), but if you don't have them you get a ton of missing device spam. i'll add a comment

[smalis-msft]

We're gonna need a more scalable solution to different isolations and different support statuses of different features.

[chris-oo]

yeah, i'm not sure what the best answer is tbh. hyper-v has a similar issue (and similar mess, imo).

[smalis-msft]

Probably something more type-driven by the IsolationType enum? Like you'd call config.isolation_type.make_foo_device() and it'd either work or error?

[github-actions]

2 Petri tests failed (1 unstable)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

openvmm/openvmm_core/src/worker/dispatch.rs:1208

• The SNP validation block rejects legacy disk paths, but it does not reject unsupported PCI/PCIe devices. That allows non-virtio PCIe devices (or vpci/pci_chipset devices) to slip through in non-CLI configurations, even though SNP bring-up is intended to support only virtio devices attached via PCIe.

            if !cfg.floppy_disks.is_empty()
                || !cfg.ide_disks.is_empty()
                || !cfg.virtio_devices.is_empty()
            {
                anyhow::bail!("KVM SNP guest_memfd does not support disks");
            }

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

openvmm/openvmm_core/src/worker/dispatch.rs:1207

• The SNP validation here rejects floppy/IDE/virtio “disks”, but it doesn’t enforce the other SNP bring-up constraints already assumed elsewhere (e.g. only virtio devices attached through PCIe, no vpci/pci-chipset devices). That means a non-CLI caller can construct an SNP config that passes this check but later fails in less obvious ways or violates the intended support matrix.

Consider extending this block to reject non-virtio PCIe devices and other PCI/vPCI devices, matching the CLI validation (and PR description) so the invariant is enforced centrally.

            if !cfg.floppy_disks.is_empty()
                || !cfg.ide_disks.is_empty()
                || !cfg.virtio_devices.is_empty()
            {
                anyhow::bail!("KVM SNP guest_memfd does not support disks");

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

vmm_core/virt/src/x86/mod.rs:525

• snp_c_bit_from_cpuid returns the raw CPUID C-bit position without sanity-checking it. If the host (or a buggy VMM) reports a value that falls in the flag bits (e.g. < 12) or aliases NX (bit 63), the loader will OR that bit into every PTE and can generate invalid page tables or unexpected execution permissions.

Consider rejecting obviously-invalid C-bit positions up front (treat as “no SNP C-bit support”).

    let [eax, ebx, _, _] = cpuid(CpuidFunction::ExtendedSevFeatures.0, 0);
    ExtendedSevFeaturesEax::from(eax)
        .sev_snp()
        .then(|| ExtendedSevFeaturesEbx::from(ebx).cbit_position())
}

[github-actions]

1 Petri tests failed (0 unstable)