Fall back from --cpu-profile auto to a host profile, with a warning, on CPUs that no built-in profile serves

Summary

A cold boot with --cpu-profile auto, the default, fails with E_PROFILE_HOST_UNKNOWN on every CPU that no built-in profile serves, such as Cascade Lake, Sapphire Rapids, Granite Rapids, Tiger Lake, Meteor Lake, and AMD's Ryzen CPUs. --cpu-profile host (#394) boots such Intel and AMD hosts, but only after the user opts in following the failure; otherwise each CPU waits for a pinned profile (#408, #409). This includes the Granite Rapids runners of Copilot cloud agent sessions, where test-microvm always uses auto.

Firecracker needs no per-model catalog to boot: by default it presents what KVM supports, normalized per vendor and never per model, and it leaves a uniform fleet to CPU templates that operators derive themselves. NVX's closest equivalent is the host profile, which derives from this host under the built-in profiles' derivation policy and is verified as a built-in profile is.

This issue tracks making auto fall back to a host profile on those CPUs. The fallback is not silent: every cold boot that uses it warns, and the warning invites the user to open an issue with the CPU's fingerprint, so that the CPU gets a built-in profile. This reverses the rule that "auto never falls back to a host profile" (#394), a spec decision that #390 called out. Host qualification is unchanged.

Behavior

A cold boot with --cpu-profile auto:

Explicit profile IDs, --cpu-profile host, restores, which take the snapshot's profile, and --cpu-fingerprint are unchanged. doctor H2 still fails with E_PROFILE_HOST_UNKNOWN and H3 still rejects a host profile, so CI and benchmark hosts keep needing a built-in profile.

A fallback has the limits of --cpu-profile host:

• It isn't pinned: a microcode, firmware, hypervisor, or OS update can change it.
• Each cold boot fingerprints the backend first: 5.5 ms on WHP, 11 to 23 ms on KVM, and 52 ms on MSHV, as measured in #394.
• Its snapshots restore only on a host with the same CPU model and stepping whose hypervisor supports the profile.
• If the host profile can't boot, for example because the hypervisor lacks a CPU feature that the time ABI requires (E_PROFILE_UNSUPPORTED), the error must say that auto fell back to it.

The warning

OpenVMM already warns that a --cpu-profile host profile isn't pinned. The fallback applies wherever auto is selected, the management endpoint included, so OpenVMM, not run, logs one warning per cold boot that falls back, at the default log level, with a stable marker that run, tests, and log scrapers can match. It names the host CPU (vendor, display family/model/stepping, and brand string), the host profile and its digest, and the limits above, and invites the user to contribute. For example:

WARN no built-in CPU profile serves this host's CPU, GenuineIntel 6/173/1 (Intel(R) Xeon(R) 6973P-C):
--cpu-profile auto fell back to intel.host.v1 (sha256 ...), a profile derived from this host for
development. It is not pinned, and its snapshots restore only on hosts of the same CPU model and
stepping. Help NVX add a built-in profile for this CPU: run
  openvmm --hypervisor kvm --cpu-fingerprint fingerprint.json
and attach fingerprint.json to a CPU profile request:
  https://github.com/microsoft/nvx/issues/new?template=cpu-profile.yml

The fingerprint holds the CPU's identity and microcode, the OS kind and build, the hypervisor's interface, and the CPUID, XSAVE, MSR, and time surface that the backend supports. It holds no hostname, user name, or serial number.

CPU profile requests

Add an issue form, .github/ISSUE_TEMPLATE/cpu-profile.yml, which the warning and run link to, prefilling the CPU from the URL's query where the form allows. It asks for:

• the CPU's name and its display family, model, and stepping;
• the backend (KVM, MSHV, or WHP), the OS build, and whether the host is bare metal or a VM, with its cloud SKU;
• the attached fingerprint, and fingerprints from the generation's other backends where available, because a profile is the intersection of its backends' fingerprints and released profiles are immutable;
• optionally, whether test-microvm passes on the fallback.

Maintainers link each request to #408 or #409, which explain how a fingerprint becomes a pinned profile.

Plan

• In nanvix/openvmm:
  • Fall back in select_on_host (openvmm/openvmm_core/src/worker/dispatch/time_abi.rs), where auto now appends the --cpu-profile host hint: when cpu_profile::select fails with E_PROFILE_HOST_UNKNOWN and cpu_profile::supports_host_profiles serves the host, derive the host profile as --cpu-profile host does, check its generation, and warn.
  • Add a test hook that makes auto treat the host as unknown, so that CI's runners, which built-in profiles serve, exercise the fallback.
  • Update cpu_profile_selection, auto_names_host_profiles_only_where_they_serve, and auto_names_host_profiles_where_the_backend_lacks_the_profile in the same file, and add tests for the fallback and its warning, a Hygon host that still fails, a fallback that cannot boot, and the restore of a fallback's snapshot.
  • Update the Guide: --cpu-profile in Guide/src/reference/openvmm/management/cli.md, and Guide/src/user_guide/openvmm/snapshots.md.
• In NVX, promote that OpenVMM revision, then:
  • Add the issue form.
  • run: replace host_cpu_unsupported_guidance in scripts/nvx_tools/time_abi.py, which says that auto fails on such CPUs, and its tests in scripts/test_time_abi.py and scripts/test_nvx_tools.py.
  • benchmark: refuse a fallback, or record it and keep its results out of performance history, because its cold boots include a fingerprint.
  • Confirm that doctor H2 and H3 still fail on such a host, so that CI's microVM jobs still require a built-in profile.
  • Update doc/design/time-abi.md (the "No implicit fallbacks" goal, Selection, Host profiles, the failure codes, and the Guide appendix), doc/usage.md (--cpu-profile, the E_PROFILE_HOST_UNKNOWN paragraph of run, and CPU profiles), and .github/copilot-instructions.md, which says that every microVM cold boot fails on a Granite Rapids runner.
• Run test-microvm with the default auto on a host that no built-in profile serves, such as a GitHub-hosted Granite Rapids runner on KVM, and on WHP and MSHV hosts where available.

Open decisions

• Should auto also fall back when the backend doesn't support the CPU's built-in profile (E_PROFILE_UNSUPPORTED)? Proposed: no. That reveals a profile or hypervisor problem on a supported generation, and OpenVMM already names --cpu-profile host there.
• Should a strict selection, such as --cpu-profile pinned, keep today's failure for scripts that need a built-in profile? doctor already rejects host profiles, so CI doesn't need one.
• Should the warning of an explicit --cpu-profile host carry the invitation too?