Repository navigation
OpenVMM/microVM umbrella: VM time and the time ABI #1183
Description
Objective. The time ABI's downtime limit and command-line guard hold; its time samples meet their bound on NVX's hosts and runners; a restore keeps the guest's TSC, its LAPIC timer, and VM time consistent across the downtime; and VM time behaves correctly on every path that a microVM takes.
Children.
| Issue | Scope | Blocked by |
|---|---|---|
| #1145 | The time ABI's clock-token guard misses Linux's byte whitespace. | — |
| #516 | Extend the maximum snapshot downtime from 30 days to 365. | #1164 |
| #1371 | After a restore, the guest's TSC leads VM time, which drives the emulated devices' timers, by the window from the restore anchor to the start of VM time. | — |
| #1366 | On KVM, a restored one-shot LAPIC timer that has expired fires once more, and a running one fires early by the time that KVM ran it outside the downtime. | — |
| #1390 | KVM_SET_LAPIC cannot tell an expired one-shot timer whose interrupt the guest took from one whose interrupt KVM has not injected, so it fires both again; an exact restore needs an opt-in KVM change. |
— |
| #1375 | The restore's log line of phase durations panics if the host's monotonic clock steps back. | — |
| #1309 | On the WHP runner azure-windows-1, a cold boot's time sample exceeded the 100 µs bound, and a clone's repair failed with 195, so both guests powered off. |
— |
| #1317 | The same cold-boot failure on azure-windows-4. |
— |
Order. #516 is blocked by #1164 (the RTC's periodic catch-up). Restore advances VM time and the RTC by the downtime, and the RTC's periodic timer then catches up one period per iteration: about 21 billion iterations after 30 days at 8192 Hz. Bound that catch-up before allowing twelve times the downtime. No other child blocks another.
Notes.
- vmtime time-source task spins forever on a timeout half the ring past the start time #1069, openvmm: registering a time source while VM time runs from a nonzero start panics #1142, and openvmm: cancelling a VM-time stop leaves the owner running after its keepers stop #1166 (VM time) moved to OpenVMM/microVM umbrella: OpenVMM issues outside the microVM and NVX implementation #1186: no microVM path reaches them.
- The PIT's similar catch-up (PIT
Timer::evaluateis O(elapsed ticks / count); one PIO access after idle time can take hundreds of ms #1067) already skips whole periods at NVX's OpenVMM pin. - openvmm: on KVM, a restored one-shot LAPIC timer can fire an extra time or drift #1366's drift and openvmm: after a microVM restore, the TSC leads VM time by the restore's length #1371 both come from windows around the capture and restore anchors that no downtime covers. Their fixes, and openvmm: time-ABI restore panics in a log line if the host clock steps back #1375's, change
LoadedVm::time_abi_restoreor its LAPIC advance; land them one at a time. openvmm: on KVM, a restored one-shot LAPIC timer can fire an extra time or drift #1366's other cases, and openvmm: a restored non-Fixed APIC timer makes KVM inject INIT, SIPI or NMI #1365 (in OpenVMM/microVM umbrella: processor state across snapshots #1182), change how a restore writes the LAPIC timer. openvmm: KVM_SET_LAPIC fires an expired, already delivered one-shot timer again #1390 is openvmm: on KVM, a restored one-shot LAPIC timer can fire an extra time or drift #1366's KVM half, which only an opt-in KVM change can make exact. - ci: a cold boot's time sample exceeded 100 µs, and a clone's repair failed with 195, on azure-windows-1 (flaky NVX microVM tests / Windows / WHP / Runtime adapter) #1309 and ci: a cold boot's time sample exceeded 100 µs on azure-windows-4 too (flaky NVX microVM tests / Windows / WHP / Runtime adapter) #1317 are CI flakes whose probable cause is a runner condition, not a change. Their logs lost OpenVMM's
time ABI: guest TSC offsetline, which would tell ci: a cold boot's time sample exceeded 100 µs, and a clone's repair failed with 195, on azure-windows-1 (flaky NVX microVM tests / Windows / WHP / Runtime adapter) #1309's two mechanisms apart; ci: a cold boot's time sample exceeded 100 µs on azure-windows-4 too (flaky NVX microVM tests / Windows / WHP / Runtime adapter) #1317 proposes keeping it first. - openvmm: restoring an extreme snapshot RTC time overflows the RTC clock #1376 (in OpenVMM/microVM umbrella: PIC, PIT, RTC, and IOAPIC emulation #1184) bounds the RTC's clock, which a restore advances by the downtime.
Activity