[Pedro Henrique Penna (ppenna)]

Fixes #928
Part of #409

Pins microsoft/openvmm#4769 at d2338ea22c36135b468e7f3ae168066b6c9efde9, two commits on 57d0a18b3, the previous pin, which is the head of feature/microvm/dev. It adds amd.genoa.v2, a second revision of the Genoa CPU profile, which --cpu-profile auto selects on every Genoa host, so the Azure Genoa VMs whose Microsoft hypervisor cannot present amd.genoa.v1 cold-boot on a built-in profile.

Why

amd.genoa.v1 pins what the KVM of the GitHub-hosted runner that it derives from presents on an EPYC 9V74: the basic leaves up to 0x1c, and LFENCE serialization, NoSmmCtlMsr, and the TSA immunities in CPUID 0x80000021. The Microsoft hypervisor of the Azure Genoa VMs fingerprinted so far presents none of them, under nested MSHV (#409, Standard_D64als_v6) and nested WHP (#928, Standard_D8ads_v5) alike, so every cold boot with auto there fails before the guest runs:

[E_PROFILE_UNSUPPORTED] the hypervisor's processor features cannot present CPU profile amd.genoa.v1: they lack tsa_l1_no_support, tsa_sq_no_support

amd.genoa.v2 is amd.genoa.v1 without them (sha256:8ee00e9e…), derived from the runner's KVM fingerprint and the #409 MSHV host's. Its Linux guests report TSA as vulnerable, as amd.milan.v1's do. amd.genoa.v1 stays pinned, so --cpu-profile amd.genoa.v1 still selects it and its snapshots still restore. Against the #928 fingerprint, amd.genoa.v2 passes the cold boot's processor-feature check and has no CPUID violation; the two CET XSAVE subleaves that the fingerprint's probe partition shows are read on a partition configured from the profile, as for amd.milan.v1 on the Azure WHP host whose processor features this host's WHP offers exactly. microsoft/openvmm#4769 records that host as a test fixture.

Changes

1. openvmm: pin amd.genoa.v2 for Genoa hosts without the TSA immunities (d2d1971f5): the gitlink, and the coordinated changes that the new profile revision needs, since NVX's two copies of the catalog assumed one profile per generation:
   • nvx-rs/src/host/cli/cpu_generations.json, which copies the identity of every pinned profile, gains amd.genoa.v2, and nvx-rs run's guidance lists each generation that the built-in profiles cover once.
   • scripts/nvx_tools/time_abi.py's copy records the latest revision of each generation's profile (CpuGeneration.revision, which takes no part in comparisons), which doctor --no-openvmm reports, and test_the_catalog_copy_matches_openvmm_pinned_profiles compares every revision with the pinned profiles.
   • doc/usage.md and doc/ci.md name amd.genoa.v2 as Genoa's profile.
2. doc: map the Genoa profile revision in the OpenVMM roadmap (3be659044): positions 348 and 349, unassigned like 341-343, 346, and 347, and the new pin, now 192 commits past the mapped tip; [DONT REVIEW] microVM: let a platform restore install a new network policy on a NIC template openvmm#4767 merged positions 346 and 347.

Not in scope: Turin, whose amd.turin.v1 pins the same maximum basic leaf and 0x80000021 values and likely fails the same way on these hypervisors (unverified), and the qualification of Genoa hosts on MSHV and WHP with doctor and test-microvm, which needs AMD hosts that CI lacks.

Dependency

• [DO NOT REVIEW] cpu_profile: pin amd.genoa.v2 for Genoa hosts without the TSA immunities openvmm#4769, open, based directly on 57d0a18b3; this PR pins its head, d2338ea22, itself (tree cd7a694ba56bff4fe3b024056141128c12fc6f85), so no equivalence argument is needed. Both OpenVMM commits carry good signatures. Merge this PR only after #4769 lands on feature/microvm/dev with these commits; if its merge rewrites them, this PR's pin must move to the merged revision.

Validation

NVX head submitted to CI: 3be659044c418f8dffef156539175cccab180c6d, directly on dev at b65df4781.

microsoft/openvmm#4767 and #931 landed while this PR waited, so both PRs were rebased. OpenVMM's two commits moved from e68871cc6 to 57d0a18b3 (b61b4b363 became d2338ea22); git range-diff shows identical patches, and only the first commit's port note changed, to name the new base. This PR's commits were rebuilt on b65df4781: the promotion commit differs from its first revision only in the gitlink and its message's pin paragraph, and the roadmap commit numbers OpenVMM's commits 348 and 349, after #931's 346 and 347.

• OpenVMM, at d2338ea22 on Windows with Rust 1.95.0, and before the rebase at b61b4b363: cargo clippy --all-targets -p cpu_profile -p virt_whp -- -D warnings, cargo doc --no-deps for both with -D warnings, cargo nextest run --profile agent -p cpu_profile -p virt_whp (162 passed, 17 skipped), and cargo xtask fmt --fix (clean). OpenVMM's check_fingerprint example reproduces CPU profile: Standard_D8ads_v5 / EPYC 9V74 fails amd.genoa.v1 on WHP #928's failure exactly at e68871cc6.
• Promotion comparisons: openvmm_vectors passes unchanged, and openvmm_cpu_profiles and test_the_catalog_copy_matches_openvmm_pinned_profiles failed on the bare gitlink and pass with the coordinated changes.
• On Windows, at this PR's first revision, a5385715a on 612d2ff31, whose code changes this head repeats unchanged:
  • check-quality's Python and Markdown checks: ruff check, ruff format --check, pyright for Linux and Windows, and check_markdown_links.py.
  • validate-nvx's Windows steps: compileall, the unittest list (1,365 tests), test_adversarial.py, test_hosts.py, and nvx.py verify. All pass except seven tests of test_setup_azure and test_microvm_tests that run Linux shell scripts under Git Bash on this host; they fail identically at the base 2d56df65f.
  • check-nvx-rs's steps that run on Windows: cargo fmt --check, the three Clippy configurations, the tests with all, default, and no features, cargo doc with -D warnings, the MSRV check with 1.89, and the runtime adapter's protocol-only and host-only configurations.
• At 3be659044: nvx.py verify, ruff check, ruff format --check, pyright for Linux and Windows, check_markdown_links.py, test_time_abi.py (70 tests), test_nvx_tools.py's benchmark, CPU-profile, and doctor tests (28), openvmm_cpu_profiles, openvmm_vectors, nvx-rs's cpu_profile tests, and cargo fmt --check.
• Left to CI: the Linux gates, the guest builds, both OpenVMM suites, and the KVM, MSHV, and WHP jobs, all on Intel runners. No CI runner has an AMD CPU, so no job cold-boots amd.genoa.v2; CPU profile: Standard_D8ads_v5 / EPYC 9V74 fails amd.genoa.v1 on WHP #928's reporter is asked to qualify their host.

[Copilot]

🔵 Needs a closer look

Human verification is needed because OpenVMM #4769 remains unmerged and the changed Genoa CPUID surface lacks exact-pin AMD/WHP cold-boot and restore qualification.

No open issues 🎉

What changed in this PR

Integrates the amd.genoa.v2 profile into NVX’s catalogs and guidance to support Genoa hosts whose hypervisors lack features required by v1, addressing #928 and advancing #409. Genoa qualification on MSHV and WHP remains pending.

Changes:

• Records Genoa v2 as the latest profile while preserving v1 in the Rust catalog.
• Updates catalog consistency tests and deduplicates CPU generations in CLI guidance.
• Documents profile compatibility, qualification limits, and the OpenVMM pin’s roadmap position.

File	Description
scripts/​test_time_abi.py	Tests latest-revision selection and catalog consistency across revisions.
scripts/​nvx_tools/​time_abi.py	Tracks profile revisions and selects Genoa v2.
nvx-rs/​src/​host/​cli/​cpu_profile.rs	Lists each CPU generation once in guidance.
nvx-rs/​src/​host/​cli/​cpu_generations.json	Adds Genoa v2 alongside v1.
doc/​usage.md	Explains revision selection, compatibility, and qualification limits.
doc/​openvmm-upstream-roadmap.md	Records the new pin and two Genoa-related commits.
doc/​ci.md	Updates doctor documentation for latest-revision reporting.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The default Genoa profile lacks exact-pin AMD cold-boot and snapshot qualification, while prerequisite OpenVMM #4769 remains open with exact-head CI pending.

No open issues 🎉

_{Review effort: Balanced}