Repository navigation
OpenVMM/microVM umbrella: OpenVMM issues outside the microVM and NVX implementation #1186
Description
Objective. Keep apart the OpenVMM issues that concern neither the microVM nor NVX's implementation. No NVX microVM reaches the code that they change, so fixing them changes nothing that an NVX microVM does. Most of them are in code that the microVM shares with OpenVMM's standard VMs, so they can also be fixed or reported upstream.
Standard-VM features that microVMs lack. The microVM boots its kernel directly, without PCAT or UEFI firmware, and has no PCI, PCIe, vPCI, or VMBus, no PM device, and no Hyper-V enlightenments or isolation (openvmm/openvmm_defs/src/microvm.rs).
| Issue | Scope | Why no NVX microVM reaches it |
|---|---|---|
| #135 | The last OpenVMM VMM tests that NVX CI excludes. Its sub-issues are #183 (PCAT firmware for the Linux KVM and MSHV PCAT tests) and #184 (the MSHV PCIe save/restore pulse hang). | They test PCAT boots and PCIe save/restore. |
| #170 | Linux/KVM UEFI boot tests stall on lazily fetched VHD reads. | The microVM uses neither UEFI nor lazily fetched disks. |
| #393 | OpenVMM aborts while stopping the VM in MSHV ttrpc::test_ttrpc_interface. |
The test's VM is a standard VM, with SCSI over VMBus, vPCI, and PCIe NVMe and virtio-blk. The root cause is not yet known; if it lies in MSHV partition teardown, which microVMs share, move the issue back. |
| #1156 | VPCI hot removal closes the chipset bus while VPs can still access it. | microVMs have no VMBus or VPCI. |
| #1377 | A KVM partition with Hyper-V enlightenments and more than 2024 VPs panics while it claims their SynIC routes. | microVMs have no Hyper-V enlightenments. |
| #1383 | Saving or inspecting a KVM AP in SEV-ES/SNP reset hold panics. | microVMs run without isolation. |
| #1384 | offset_of overflows for a port-I/O or MMIO region that ends at the address maximum. |
No microVM device calls it, as the issue notes; in the chipset crate, only the PIIX4 PM device does. |
Shared code that no microVM or NVX path reaches.
| Issue | Scope | Why no NVX microVM reaches it |
|---|---|---|
| #1155 | Accepted state-unit dependency cycles hang lifecycle operations past their timeout. | Normal microVM construction creates no such cycle, as the issue notes. |
| #1165 | A removed dependency leaves a partial registration that can misroute restored state. | In-tree construction does not race dependency removal, as the issue notes. |
| #1166 | Cancelling a VM-time stop leaves the owner running after its keepers stop. | The microVM's unit dispatcher never drops a stop; only other API callers can, as the issue notes. |
| #1069 | The vmtime time-source task spins forever on a timeout half the ring past the start time. | It needs a timeout about 29,000 years ahead. The microVM's devices set none, and the issue's only guest lead is OpenHCL's synthetic timer. |
| #1142 | Registering a time source while VM time runs from a nonzero start panics. | OpenVMM builds its only VM-time source during VM construction, while VM time is stopped (openvmm/openvmm_core/src/worker/dispatch.rs). |
| #1159 | KVM CPU reset keeps a pending NMI and the interrupt shadow. | A microVM guest cannot request a reset: it has no i8042, ACPI PM, PCI reset, or UEFI, its shutdown port only powers off, a triple fault halts by default, and the time ABI's MSR filter makes Hyper-V's reset MSR raise #GP. NVX's launches run the REPL headless, and a restore starts on fresh vCPUs. |
| #1167 | A ReadMemory RPC with an excessive size crashes the VM worker. |
Only the interactive REPL sends ReadMemory, and NVX's launches run it headless (--microvm-control-auth-stdin). |
| #1374 | A gdb Break on a paused VM records a debug-break halt, which a later save keeps. |
NVX's launches never pass --gdb, so no debugger attaches. |
| #1386 | On KVM, a halted VP with a PV kick waiting restores as running. | Every microVM has a time ABI, under which KVM refuses the kick, as the issue notes, and a restore starts on fresh vCPUs. |
| #1388 | On an AMD KVM host, binding a VP of a guest whose CPUID names GenuineIntel fails on IA32_FEATURE_CONTROL. |
With a time ABI, which every microVM has, the generation check refuses an Intel profile on an AMD host before the partition is built, as the issue notes. |
| #1387 | A chipset device whose add fails stays a target of its line sets. | The microVM's load returns the add's error, as the issue notes. |
| #1378 | Host CPUID with 0 or more than 32768 VPs per socket panics the topology. | The microVM starts from TopologyBuilder::new_x86(), not from the host's topology, as the issue notes. |
| #1379 | Intel topology CPUID panics above 4096 reserved VPs per socket. | The microVM has at most 8 VPs, in one socket, as the issue notes. |
| #1240 | consomme's test_tcp_last_ack_restarts_timeout_after_close_wait races a 1 ms close deadline, so a runner stall hangs OpenVMM's Windows unit tests. |
The defect is in the test, not in consomme. Upstream fixed it in microsoft/openvmm#4852 (ddbb365ff), which NVX's pin, 0e46a01e, includes. |
Order. No child blocks another, and no issue elsewhere in #1185 is blocked by one of them.
Notes.
- If one of these turns out to reach a microVM, move it back to the matching area umbrella under OpenVMM/microVM umbrella: every open OpenVMM and microVM issue, by area #1185.
- openvmm: VPCI hot removal closes the chipset bus while VPs can still access it #1156 shares openvmm: snapshot input gating closes device mutexes while other vCPUs still access them #1138's pattern: a
CloseableMutexstays closed across an asynchronous wait while vCPUs can still lock it. - openvmm: KVM CPU reset retains a pending NMI and interrupt shadow #1159, openvmm: saving or inspecting a KVM AP in SEV-ES/SNP reset hold panics #1383, and openvmm: on KVM, a halted VP with a PV kick waiting restores as running #1386 change
KvmVpStateAccess::{activity, set_activity}, as five of OpenVMM/microVM umbrella: processor state across snapshots #1182's children do; land them in turn with those. - openvmm: host CPUID with 0 or over 32768 VPs per socket panics topology #1378 and openvmm: Intel CPUID generation panics above 4096 reserved VPs per socket #1379 both concern the topology's VPs per socket: openvmm: host CPUID with 0 or over 32768 VPs per socket panics topology #1378 the count that
from_cpuidaccepts, and openvmm: Intel CPUID generation panics above 4096 reserved VPs per socket #1379 the sharing count that Intel's leaf 4 encodes.
Metadata
Metadata
Assignees
Labels
No labels
Activity
test_tcp_last_ack_restarts_timeout_after_close_waitraces a 1 ms close deadline, so a runner stall hangs it until nextest kills it (flaky OpenVMM unit tests / Windows) #1240