Repository navigation
time ABI: boot AMD CPUs on an EPYC Milan profile and AMD host profiles - #404
Merged
Pedro Henrique Penna (ppenna) merged 3 commits intoOct 6, 2026
Merged
Conversation
Copilot started reviewing on behalf of
Pedro Henrique Penna (ppenna)
October 6, 2026 09:06
View session
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
AMD issue guidance conflicts with the stated tracking scope, and the benchmark documentation omits required performance-pipeline wiring.
Review effort: Balanced
Findings: 3
Open (3)
What changed in this PR
Adds AMD EPYC Milan and AMD host-profile support to NVX’s time ABI.
Changes:
- Pins OpenVMM’s AMD CPU-profile implementation.
- Adds Milan catalog mapping, guidance, tests, and documentation.
- Separates future AMD performance series and reports Copilot runner CPUs.
| File | Description |
|---|---|
openvmm |
Pins AMD profile support. |
scripts/nvx_tools/time_abi.py |
Adds AMD mappings and guidance. |
scripts/test_time_abi.py |
Tests Milan catalog behavior. |
scripts/test_nvx_tools.py |
Tests AMD run guidance. |
doc/design/time-abi.md |
Specifies AMD ABI behavior. |
doc/usage.md |
Documents AMD profiles. |
doc/setup.md |
Updates host prerequisites. |
doc/ci.md |
Adds Milan qualification details. |
doc/benchmarks.md |
Describes AMD performance-series isolation. |
.github/workflows/copilot-setup-steps.yml |
Reports runner CPU details. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Bump OpenVMM to 07850d27a (nanvix/openvmm fix/amd-cpu-profiles-396), which supports AMD CPUs in the time ABI's CPU profiles. Until now, every cold boot on an AMD host failed with E_PROFILE_HOST_UNKNOWN, --cpu-profile host refused AMD CPUs too, and run pointed AMD hosts to #396. - d290df675 accepts AMD CPUs (AuthenticAMD, vendor ID amd) in profiles and host profiles: --cpu-profile host derives amd.host.v1 on an AMD host. The derivation policy gains AMD rules, which leave the Intel profiles' derivation unchanged: AMD's cache, topology, and speculation leaves keep data, SVM, IBS, LWP, the performance counter extensions, MONITORX, RDPRU, PPIN, CPPC, SME, and SEV are cleared, and the speculation controls and immunities stay, except what KVM cannot present: BTC_NO, which KVM never enumerates, and PSFD without a SPEC_CTRL control, without which KVM denies a guest SPEC_CTRL. AMD's topology fields are VM-owned in AMD profiles only, and OpenVMM shares the L3 cache across the socket in 0x8000001D as it does in leaf 4. auto's errors now also name --cpu-profile host where the backend does not support the built-in profile (E_PROFILE_UNSUPPORTED), on Intel and AMD hosts. - 905993c36 maps the Hyper-V processor feature banks to AMD's CPUID bits, so MSHV and WHP partitions of an AMD profile keep SPEC_CTRL and PRED_CMD. - 933c1de0c serves AMD's HWCR (TscFreqSel) and DE_CFG (LFENCE serialization), which Linux reads at boot, on every backend under AMD profiles, and has MSHV present 0x8000001E per VP. TOPOEXT stays. - 07850d27a pins amd.milan.v1 (family 25, model 1, every stepping), which the policy derives from the WHP fingerprint of an Azure EPYC 7763 VM, digest sha256:463ee0368dc01bf56a3ab1157d62b21b51d11b3dcccb46c804864748ef696543. The four Intel profiles' files and digests are unchanged. NVX follows the pin: - time_abi's copy of the catalog gains milan (AuthenticAMD 25/1, amd.milan.v1) and PROFILE_VENDORS AuthenticAMD; the unit test compares the copy with the pinned revision's profiles. HOST_PROFILE_VENDORS adds AuthenticAMD, as OpenVMM's supports_host_profiles now decides. - After a failed cold boot on a CPU that no built-in profile serves, run suggests --cpu-profile host on AMD CPUs, such as Genoa and Ryzen, as on Intel ones. It links #396, which tracks profiles for more AMD CPUs, on AMD CPUs, and #390, which tracks profiles for more CPUs, on the others. Other vendors' CPUs, such as Hygon's, still learn that host profiles serve only Intel and AMD CPUs. Where the hypervisor does not support the built-in profile, OpenVMM's own E_PROFILE_UNSUPPORTED error names --cpu-profile host, which run cannot detect, because OpenVMM keeps the terminal. - doctor needs no change: H2 reports what OpenVMM's --cpu-fingerprint reports, and without OpenVMM it maps the host with the catalog copy. - The time ABI specification drops the deferral of AMD profiles (other vendors stay a non-goal) and describes the AMD configuration MSRs and how each backend routes them, with KVM's MSR exits per boot (4 under an Intel profile, all on the BSP, and 4 + 1 + N on N vCPUs under an AMD one), AMD's VMM-owned topology fields and policy zeros, BTC_NO and PSFD included, the brand strings, AMD host profiles, auto's hint after E_PROFILE_UNSUPPORTED, KVM's zero out-of-range result for AMD guests, WHP's ninth CPUID exit (0x8000001E), the Milan catalog entry and the limits of its single fingerprint, and E_PROFILE_HOST_UNKNOWN's vendor condition. The CPU profile sections of doc/usage.md and doc/setup.md, run's guidance note, and H2's row in doc/ci.md follow. The Milan profile has no speculation controls in 0x80000008 EBX and nothing in 0x80000021, which that nested WHP does not offer, so its Linux guests use retpolines and report SSB, SRSO, and TSA as vulnerable on every host. It drops the PSFD and BTC_NO that the WHP offers, so a Milan host on KVM no longer fails it on either bit. Milan hosts on KVM and MSHV, bare-metal ones, and other SKUs are still unverified, and so are the AMD paths of the KVM and MSHV backends. Validated on that host, an AMD EPYC 7763 (25/1/1) Azure Standard_D16as_v5 VM with Windows 11 build 26200 and nested WHP, with OpenVMM built at 07850d27a (provenance source_clean): - nvx.py verify passes, and doctor --backend whp --checks H1 H2 H3 passes: H2 reports generation=milan profile=amd.milan.v1 profile_digest=sha256:463ee0368dc01bf56a3ab1157d62b21b51d11b3dcccb46c804864748ef696543, also with --no-openvmm, and H3 cpu_profile=amd.milan.v1 tsc_hz=2445430803 lapic_hz=200000000. - test-microvm --backend whp passes its full default suite, 34 runs with the virtio-fs share scenarios, in 5.5 minutes: 29 warp runs within 33 ns and no backward step, every boot, capture, and restore within its CPU budget, and no downtime stall. With the Ubuntu and Azure Linux guests, guest-boot and time-abi-conformance pass too. - A cold boot, capture, and restore at 4 vCPUs pass with auto (amd.milan.v1) and with --cpu-profile host (amd.host.v1): every phase reports status=ok, and dmesg has no Firmware Bug, unchecked MSR access, or APIC ID mismatch line. The BSP reads HWCR once (0x1000000), each vCPU reads DE_CFG once (0x2), and neither profile shows the guest PSFD or BTC_NO. - --cpu-profile intel.skylake-sp.v1 fails with E_CPU_GENERATION, and restoring either snapshot with the other's profile fails with E_PROFILE_UNKNOWN. - compileall, the validate-nvx unit tests (740), test_adversarial.py, the host-connect tests, every --help, ruff check and format, and pyright for Linux and Windows pass. The Intel guidance tests pass unchanged. Part of #396. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01c35bf1-81da-4f98-8380-8a902ac0e5f9
The CI performance series are named by OS, backend, and host type (linux-kvm-virtual-machine, linux-mshv-virtual-machine, and windows-whp-virtual-machine), not by CPU vendor (#396, plan item 7). That is sound only while every CI microVM runner has an Intel CPU, as every one does: Azure VMs with Ice Lake-SP or Emerald Rapids Xeons. With amd.milan.v1 pinned, an AMD runner can boot microVMs, on a built-in AMD profile, since CI never uses host profiles, and through AMD-V; only Milan CPUs have such a profile so far. An AMD runner that joined one of these series would skew its baseline. doc/benchmarks.md now says why no AMD series exists yet and what an AMD runner needs before it joins CI: series of its own, named with an -amd suffix such as linux-kvm-virtual-machine-amd, in performance.py's PLATFORM_NAMES and OPENVMM_BACKENDS and in the CI matrix, so that its history lives in separate data/ files. Local measurements on AMD hosts can keep the existing names, because only CI records history. No tooling changes: with no AMD runner, such series would have no samples to test. Part of #396. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01c35bf1-81da-4f98-8380-8a902ac0e5f9
Copilot cloud agent sessions run test-microvm --backend kvm on GitHub-hosted ubuntu-latest runners, whose CPUs vary: GitHub-hosted runners commonly report AMD EPYC CPUs as well as Intel Xeons (#396, plan item 8). The CPU decides the CPU profile that a cold boot's --cpu-profile auto selects, and so whether a session can boot microVMs at all, but the setup steps logged only the CPU count, and no other log of these runners names the CPU. The environment summary now has a CPU row, with the vendor, family, model, and stepping as NVX names them and the model name, for example "AuthenticAMD 25/1/1 (AMD EPYC 7763 64-Core Processor)", for which auto selects amd.milan.v1; whether a runner's nested KVM supports that profile is unverified, because no AMD KVM host has run it. The awk script reads only the first processor of /proc/cpuinfo; it printed that example with mawk and gawk in Debian and Ubuntu 24.04 containers, and shellcheck passes it. This branch's first run of the workflow reported AuthenticAMD 26/2/1 (AMD EPYC 9V45 96-Core Processor): a Zen 5 CPU, which no built-in profile serves, so a session's cold boot with auto fails there with E_PROFILE_HOST_UNKNOWN, and run suggests --cpu-profile host. Part of #396. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01c35bf1-81da-4f98-8380-8a902ac0e5f9
Pedro Henrique Penna (ppenna)
force-pushed
the
fix/issue-396-amd-cpu-profiles
branch
from
October 6, 2026 10:13
9f67e60 to
5111640
Compare
Copilot started reviewing on behalf of
Pedro Henrique Penna (ppenna)
October 6, 2026 10:14
View session
Pedro Henrique Penna (ppenna)
deleted the
fix/issue-396-amd-cpu-profiles
branch
October 6, 2026 17:25
This was referenced Oct 6, 2026
Pedro Henrique Penna (ppenna)
added a commit
that referenced
this pull request
Oct 6, 2026
Pin nanvix/openvmm 32c65671c, one commit on aa9f6c4fa. It pins amd.genoa.v1 for family 25 model 17 and amd.turin.v1 for family 26 model 2, so a cold boot with --cpu-profile auto boots AMD's fourth- and fifth-generation EPYC CPUs (#396). It also makes every AMD profile clear Intel's enumerations of its speculation controls and of IA32_ARCH_CAPABILITIES, which KVM adds on AMD hosts. #404 pinned amd.milan.v1, and other AMD generations waited for hosts that could fingerprint them. GitHub's hosted Actions runners are such hosts. They are Azure VMs whose CPU, which Copilot Setup Steps reports, is an AMD EPYC 7763 (Milan), 9V74 (Genoa), or 9V45 (Turin), or an Intel Xeon Platinum 8573C (Emerald Rapids) or Xeon 6973P-C (Granite Rapids). Copilot cloud agent sessions boot microVMs there, on KVM. A temporary workflow on a scratch branch, deleted since, ran on 22 runners in two rounds: - With release v0.1.0-dev.57eabdc503d6 (OpenVMM 07850d27a), five EPYC 7763 runners passed --cpu-fingerprint, doctor H1 to H4, and all 34 runs of the full default test-microvm suite on amd.milan.v1, which no KVM host had run. An 8573C runner passed --cpu-fingerprint, doctor H1 to H4, and 9 scenario runs on intel.emeraldrapids.v1, which no KVM host had run either. A 9V74 and a 9V45 runner failed with E_PROFILE_HOST_UNKNOWN, after --cpu-fingerprint wrote the fingerprints that the new profiles derive from. - With a KVM build of the pinned OpenVMM, each of the 13 runners of a served CPU passed: - --cpu-fingerprint and doctor H1 to H4 on its profile; - the time ABI preflight on its profile and on its host profile; - all 34 runs of the full default test-microvm suite on its profile; - the 9 runs of the guest-boot, guest-identity, smp, smp-snapshot, console-snapshot, and time-abi-conformance scenarios on its host profile. Those runners were 4 Genoa, 1 Turin, 7 Milan, and 1 Emerald Rapids. Their warp probes measured at most 37 ns, with no backward step and no CPU budget overrun. The Granite Rapids runner failed auto with E_PROFILE_HOST_UNKNOWN, and passed those 9 runs on its host profile. NVX's copy of the catalog, time_abi.CPU_GENERATIONS, gains genoa and turin, as test_the_catalog_copy_matches_openvmm_pinned_profiles requires. The usage reference's CPU profiles section, the setup guide, the CI guide's H2 row, and doc/benchmarks.md follow. The time ABI specification updates its catalog, generation names, brand strings, msrs field, AMD profiles, and the KVM row's MSR exit count, which an AMD KVM host now runs. With this, #396 is resolved, except for work that needs AMD hosts that neither the development hosts nor CI have. #409 now tracks that work: MSHV on any AMD host, Genoa and Turin on MSHV and WHP, Milan on MSHV, bare-metal AMD hosts, and AMD client CPUs. #410 tracks AMD CI runners with their own performance series, and doc/benchmarks.md links it. So for an AMD CPU that no built-in profile serves, run's guidance now links #409 instead of #396, and the usage reference does too. Validation: - On the bare-metal Xeon Silver 4114 hosts (Skylake-SP: prometheus28 with WHP, prometheus30 with MSHV, and prometheus31 and prometheus32 with KVM), and on an AMD EPYC 7763 VM with Windows 11 and WHP, the checks below pass. They used release builds of the pinned OpenVMM tree, made as b1d84c6db before its message changed, and the guest artifacts of v0.1.0-dev.57eabdc503d6: - `nvx.py verify`; - doctor H1 to H3, on intel.skylake-sp.v1 and amd.milan.v1, whose digests are unchanged; - the time ABI preflight on those profiles and on intel.host.v1 and amd.host.v1; - the full default test-microvm suite. On prometheus30, OpenVMM's MSHV hardware tests pass. On prometheus30 and prometheus32, the cpu_profile, virt_mshv, and virt_kvm unit tests pass. - On the EPYC 7763 VM, these checks pass: - compileall; - the validate-nvx unit tests (740), adversarial tests (70), and host-connect tests (4), and every `--help` check; - Ruff check and format, and Pyright for Linux and Windows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6844f112-d265-4538-bd05-aadcfe322f84
Pedro Henrique Penna (ppenna)
added a commit
that referenced
this pull request
Oct 6, 2026
Pin nanvix/openvmm 3951c8415, one commit on aa9f6c4fa. It pins amd.genoa.v1 for family 25 model 17 and amd.turin.v1 for family 26 model 2, so a cold boot with --cpu-profile auto boots AMD's fourth- and fifth-generation EPYC CPUs (#396). It also makes every AMD profile clear Intel's enumerations of its speculation controls and of IA32_ARCH_CAPABILITIES, which KVM adds on AMD hosts, and its WHP backend tests cover both profiles. #404 pinned amd.milan.v1, and other AMD generations waited for hosts that could fingerprint them. GitHub's hosted Actions runners are such hosts. They are Azure VMs whose CPU, which Copilot Setup Steps reports, is an AMD EPYC 7763 (Milan), 9V74 (Genoa), or 9V45 (Turin), or an Intel Xeon Platinum 8573C (Emerald Rapids) or Xeon 6973P-C (Granite Rapids). Copilot cloud agent sessions boot microVMs there, on KVM. A temporary workflow on a scratch branch, deleted since, ran on 22 runners in two rounds: - With release v0.1.0-dev.57eabdc503d6 (OpenVMM 07850d27a), five EPYC 7763 runners passed --cpu-fingerprint, doctor H1 to H4, and all 34 runs of the full default test-microvm suite on amd.milan.v1, which no KVM host had run. An 8573C runner passed --cpu-fingerprint, doctor H1 to H4, and 9 scenario runs on intel.emeraldrapids.v1, which no KVM host had run either. A 9V74 and a 9V45 runner failed with E_PROFILE_HOST_UNKNOWN, after --cpu-fingerprint wrote the fingerprints that the new profiles derive from. - With a KVM build of b1d84c6db, which differs from the pinned OpenVMM only in commit messages and in virt_whp's tests, each of the 13 runners of a served CPU passed: - --cpu-fingerprint and doctor H1 to H4 on its profile; - the time ABI preflight on its profile and on its host profile; - all 34 runs of the full default test-microvm suite on its profile; - the 9 runs of the guest-boot, guest-identity, smp, smp-snapshot, console-snapshot, and time-abi-conformance scenarios on its host profile. Those runners were 4 Genoa, 1 Turin, 7 Milan, and 1 Emerald Rapids. Their warp probes measured at most 37 ns, with no backward step and no CPU budget overrun. The Granite Rapids runner failed auto with E_PROFILE_HOST_UNKNOWN, and passed those 9 runs on its host profile. NVX's copy of the catalog, time_abi.CPU_GENERATIONS, gains genoa and turin, as test_the_catalog_copy_matches_openvmm_pinned_profiles requires. The usage reference's CPU profiles section, the setup guide, the CI guide's H2 row, and doc/benchmarks.md follow. The time ABI specification updates its catalog, generation names, brand strings, msrs field, and AMD profiles; the KVM row's MSR exit count, which an AMD KVM host now runs; and the WHP row's CPUID exit count, 9 for every AMD profile, since each lists 0x8000001E. With this, #396 is resolved, except for work that needs AMD hosts that neither the development hosts nor CI have. #409 now tracks that work: MSHV on any AMD host, Genoa and Turin on MSHV and WHP, Milan on MSHV, bare-metal AMD hosts, and AMD client CPUs. #410 tracks AMD CI runners with their own performance series, and doc/benchmarks.md links it. So for an AMD CPU that no built-in profile serves, run's guidance now links #409 instead of #396, and the usage reference does too. Validation: - On the bare-metal Xeon Silver 4114 hosts (Skylake-SP: prometheus28 with WHP, prometheus30 with MSHV, and prometheus31 and prometheus32 with KVM), and on an AMD EPYC 7763 VM with Windows 11 and WHP, the checks below pass. They used release builds of b1d84c6db and the guest artifacts of v0.1.0-dev.57eabdc503d6: - `nvx.py verify`; - doctor H1 to H3, on intel.skylake-sp.v1 and amd.milan.v1, whose digests are unchanged; - the time ABI preflight on those profiles and on intel.host.v1 and amd.host.v1; - the full default test-microvm suite. On prometheus30, OpenVMM's MSHV hardware tests pass. On prometheus30 and prometheus32, the cpu_profile, virt_mshv, and virt_kvm unit tests pass. - On the EPYC 7763 VM, these checks pass: - compileall; - the validate-nvx unit tests (740), adversarial tests (70), and host-connect tests (4), and every `--help` check; - Ruff check and format, and Pyright for Linux and Windows; - the pinned OpenVMM's virt_whp unit tests (36) and its WHP hardware tests (16). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6844f112-d265-4538-bd05-aadcfe322f84
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Support AMD CPUs in the time ABI's CPU profiles (#396), with nanvix/openvmm#115:
amd.milan.v1;runsuggest--cpu-profile hoston AMD hosts as it does on Intel hosts;Why
Since #325, every microVM cold boot selects a CPU profile, and only Intel profiles existed. On an AMD host,
nvx.py runfailed before the VM started withE_PROFILE_HOST_UNKNOWN.--cpu-profile host, from #394, failed the same way, because host profiles served only Intel CPUs. AMD hosts booted microVMs before #325.Commits
ee6758c4fopenvmm: serve AMD EPYC Milan hosts and AMD host profiles07850d27a. NVX's copy of the catalog gainsmilan, andPROFILE_VENDORSandHOST_PROFILE_VENDORSgainAuthenticAMD. After a failed cold boot on a CPU that no built-in profile serves,runsuggests--cpu-profile hoston AMD as on Intel, and links #396 on AMD CPUs and #390 on the others. The time ABI specification, the usage reference, the setup guide, and the CI guide's H2 row followb220a0dd3doc: keep AMD hosts out of the Intel performance seriesdoc/benchmarks.mdsays why no AMD series exists yet, and how an AMD runner would get its own-amdseries511164017copilot-setup-steps: report the runner's CPUAuthenticAMD 26/2/1 (AMD EPYC 9V45 96-Core Processor): the runner is AMDEach commit message details its changes and validation.
Pre-publication review
An independent review of the first revision found that
amd.milan.v1pinned two bits that KVM hosts can't offer:0x80000008EBX capabilities omit it.So every KVM Milan host would have failed with
E_PROFILE_UNSUPPORTED, GitHub's EPYC 7763 runners included. The fixes, folded into the commits:0x80000008EBX changed from0x30000005to0x00000005, giving digestsha256:463ee0368dc01bf56a3ab1157d62b21b51d11b3dcccb46c804864748ef696543.autofails withE_PROFILE_UNSUPPORTEDon an Intel or AMD host, OpenVMM's error now suggests--cpu-profile host.Review follow-ups
Copilot's review of the first push found three wording issues, which the commits now fold in:
run's guidance and the usage reference link Support AMD CPUs in the time ABI's CPU profiles #396 for AMD CPUs that no built-in profile serves, such as Genoa, and Track time ABI CPU support bugs: E_PROFILE_HOST_UNKNOWN on client CPUs, a CET false positive in --cpu-fingerprint, a duplicated generation table, and no guidance from run #390 for the others, matching this PR's scope (commit 1).doc/benchmarks.mdsays that an AMD runner needs a built-in AMD profile, which only Milan CPUs have so far (commit 2).Scope and exclusions
The GitHub-hosted runner of this PR's Copilot Setup Steps run reported an AMD EPYC 9V45 (family 26, model 2, Zen 5). No built-in profile serves it, so
test-microvmandrunwithautostill fail there withE_PROFILE_HOST_UNKNOWN.run --cpu-profile hostshould deriveamd.host.v1there, but that is unverified, and Support AMD CPUs in the time ABI's CPU profiles #396 tracks a profile for that generation.This is part of Support AMD CPUs in the time ABI's CPU profiles #396, which stays open for:
Hygon and other vendors get no profiles.
amd.milan.v1derives from one nested-WHP fingerprint and has no speculation controls. Its Linux guests use retpolines and report SSB, SRSO, and TSA as vulnerable.Dependencies
mainata41cf7351, which isdev's current pin. Merge it by fast-forwardingmain, as for cpu_profile: pin Alder Lake, add opt-in host profiles, and fix the fingerprint's CET false positive nanvix/openvmm#111, so that the pinned commit IDs stay. Otherwise, move the pin to the resultingmaincommit before this PR merges.Provenance
511164017959a66f69cbdc67460726c2b69cd8f2is three commits directly ondevd68859dac, which is the merge of sandbox: attach multiple virtio-fs shares with independent ro/rw modes #401 plus its performance baseline commit.07850d27af783ea8765111741763cb6d326228df(tree831cc8e98cabd7283ed988bafceab520b19df439).Validation
All of these ran on an Azure Standard_D16as_v5 VM (AMD EPYC 7763, 25/1/1) with Windows 11 build 26200 and nested WHP, with a release build of OpenVMM
07850d27awhose provenance is clean, and the guest artifacts ofdev's push run 37433743563, after #401 changed the guest inputs:nvx.py verifypasses.doctor --backend whp --checks H1 H2 H3passes. H2 reportsgeneration=milan profile=amd.milan.v1with the digest above, also with--no-openvmm, and H3 reportscpu_profile=amd.milan.v1.test-microvm --backend whpsuite passes: 34 runs, including sandbox: attach multiple virtio-fs shares with independent ro/rw modes #401's virtio-fs share scenarios. Its 29 warp runs stay within 33 ns, with no backward step and no CPU budget overrun. With the Ubuntu and Azure Linux guests,guest-bootandtime-abi-conformancepass too.auto(amd.milan.v1) and with--cpu-profile host(amd.host.v1):status=ok;psfdnorbtc_no.--cpu-profile intel.skylake-sp.v1fails withE_CPU_GENERATION, and restoring either snapshot with the other's profile fails withE_PROFILE_UNKNOWN.compileall, thevalidate-nvxunit tests (740), the adversarial (70) and host-connect (4) tests, every--help, Ruff check and format, and Pyright for Linux and Windows.CI run 37439708257 at the previous head,
9f67e609c, passed every job on attempt 2. Attempt 1 failed only the performance gate, on MSHV teardown metrics, because its MSHV platform job ran onazure-mshv-scus-z1-1, one of the new runners that measure guest-exit teardown about 26 ms slower than the baseline. That runner issue is unrelated to this PR, and attempt 2, onazure-mshv-5, found 0 regressions. The review fixes since then change only guidance text, documentation, and tests. At this head, CI run 37448382849 passed every job on attempt 2, the performance gate included. Attempt 1 failed onlyOpenVMM vmm-tests / Linux / MSHV, which ran onazure-mshv-scus-1. That runner's unpinnedstabletoolchain is Rust 1.99.0, and with it the vmm-tests build ofguest_test_uefiforx86_64-unknown-uefifails to link withrust-lld: undefined symbol: wcslen, a symbol that theuefi0.35.0 crate references. The same job passed with Rust 1.98.1 onazure-mshv-6at the previous head and onazure-mshv-1at this one, with the same OpenVMM pin. That toolchain drift, like the slowerscusMSHV runners, is unrelated to this PR. CI's microVM runners are Intel Ice Lake-SP and Emerald Rapids Xeons. CI therefore checks that Intel hosts are unchanged, and runs OpenVMM's unit and VMM tests at the pin, but no CI runner exercises the AMD paths.