You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
openvmm: host CPUID with 0 or over 32768 VPs per socket panics topology #1378
TopologyBuilder::from_cpuid accepts a VPs-per-socket count derived from host CPUID without checking the builder's own range, 1 to 32768, so such a host's VM panics later, in debug and release builds. A count of 0 divides by zero when the topology is built. A count above 32768 panics when it is encoded into an AMD guest's CPUID (an Intel guest gets truncated counts instead). The standard (non-microVM) machine and OpenHCL start from the host's topology (from_host_topology), so only a host, or a hypervisor presenting one, whose CPUID gives such a count reaches this. The microVM starts from TopologyBuilder::new_x86() and is not affected (openvmm/openvmm_core/src/worker/dispatch/microvm.rs).
Reproduction
Expected: from_cpuid refuses both of these hosts. Actual:
A host whose leaf 0xB core level has an x2APIC shift of 16 gives 1 << 16 VPs per socket, and from_cpuid and build(1) succeed. With an AMD guest CPUID, topology_cpuid then panics with "value out of bounds [0, 15]", encoding the count into leaf 0x80000008's 4-bit APIC core ID size.
An AMD host without leaf 0xB, whose leaf 0x80000008 reports NC=0 and whose leaf 0x8000001E reports two threads per compute unit, gives 1 / 2 = 0, and build(1) then panics with "attempt to divide by zero".
The new test host_topology_refuses_out_of_range_vps_per_socket feeds both layouts to from_cpuid.
Cause
TopologyBuilder::from_cpuid (vm/vmcore/vm_topology/src/processor/x86.rs) checks only threads_per_core before it stores vps_per_socket, so it bypasses the 1..=32768 range that the vps_per_socket() setter clamps to:
fix.patch makes from_cpuid return the new HostTopologyError::UnsupportedVpsPerSocket for a count outside 1..=32768, so such a host's VM fails to start with that error instead of panicking. It refuses rather than clamps, so that the guest's topology does not change silently. The bounds 1 and 32768 stay accepted. The test covers both failing layouts and both bounds. The patch adds test_with_tracing as a dev-dependency of vm_topology (with its Cargo.lock line).
Activity
tangruize commentedon Nov 8, 2026
Proposed patch
Patch against OpenVMM 3cf58a5234ed824435825c9f87187f5129219724. Save the contents below as
fix.patchand rungit apply fix.patch.fix.patch