]> www.infradead.org Git - users/dwmw2/qemu.git/commit
hw/acpi: Add vmclock device vmclock-6 pull-vmclock-20250108
authorDavid Woodhouse <dwmw@amazon.co.uk>
Sat, 15 Jun 2024 08:26:38 +0000 (09:26 +0100)
committerDavid Woodhouse <dwmw@amazon.co.uk>
Tue, 7 Jan 2025 16:22:04 +0000 (16:22 +0000)
commit6502ea82b26dc28c83fbc9c766af7a408a8ca827
tree2b56ee7a5fbc0446c278fd16bfe57d190ae5f6aa
parent6528013b5f5ba6bb3934b7f5fe57a3110680530f
hw/acpi: Add vmclock device

The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and track the precise
frequency of the counter as it changes with environmental conditions.

When a guest is live migrated, anything it knows about the frequency of
the underlying counter becomes invalid. It may move from a host where
the counter running at -50PPM of its nominal frequency, to a host where
it runs at +50PPM. There will also be a step change in the value of the
counter, as the correctness of its absolute value at migration is
limited by the accuracy of the source and destination host's time
synchronization.

The device exposes a shared memory region to guests, which can be mapped
all the way to userspace. In the first phase, this merely advertises a
'disruption_marker', which indicates that the guest should throw away any
NTP synchronization it thinks it has, and start again.

Because the region can be exposed all the way to userspace, applications
can still use time from a fast vDSO 'system call', and check the
disruption marker to be sure that their timestamp is indeed truthful.

The structure also allows for the precise time, as known by the host, to
be exposed directly to guests so that they don't have to wait for NTP to
resync from scratch.

The values and fields are based on the nascent virtio-rtc specification,
and the intent is that a version (hopefully precisely this version) of
this structure will be included as an optional part of that spec. In the
meantime, a simple ACPI device along the lines of VMGENID is perfectly
sufficient and is compatible with what's being shipped in certain
commercial hypervisors.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
hw/acpi/Kconfig
hw/acpi/meson.build
hw/acpi/vmclock.c [new file with mode: 0644]
hw/i386/Kconfig
hw/i386/acpi-build.c
include/hw/acpi/vmclock.h [new file with mode: 0644]
include/standard-headers/linux/vmclock-abi.h [new file with mode: 0644]
scripts/update-linux-headers.sh