KVM clock cleanup targets drift, jumps, and imprecise migration

The Linux KVM clock has long been an imperfect partner to the guest TSC: it could drift relative to what the guest itself computed, jump when the master clock was needlessly resnapshotted, and could not be saved and restored exactly across live migration. David Woodhouse has posted v7 of a large series that attacks all three problems and sheds a private timekeeping shadow copy KVM had been maintaining for years.

The imprecision came from computing kvmclock from the host TSC without applying guest TSC scaling, so the value the hypervisor advertised systematically diverged from the value guests derived from their own counters. Gratuitous master-clock update requests forced fresh reference snapshots whose arithmetic rounding yanked the guest clock even when nothing real had changed. And the existing KVM_GET_CLOCK / KVM_SET_CLOCK ioctls only let userspace pin the clock to a UTC instant, which is inherently fuzzy; there was no way to keep the exact arithmetic link between guest TSC and kvmclock when a VM moved.

The series fixes the scaling and update paths, collapses redundant per-vCPU master-clock work under the lock so only one vCPU performs each update, and tears out the pvclock_gtod_data machinery that duplicated kernel timekeeping. In its place KVM uses the generic ktime snapshot interfaces. New uAPI follows: KVM_GET_CLOCK_GUEST and KVM_SET_CLOCK_GUEST exchange the actual pvclock structure so userspace can correct kvmclock_offset and keep the TSC relationship intact across live update or migration, while KVM_VCPU_TSC_SCALE reports the effective scale ratio and frequencies needed to migrate TSC state and to fill Xen and generic timing CPUID leaves from userspace instead of having KVM patch them at runtime.

Selftests cover the correction path, master-clock behaviour with differing TSC offsets, and migration-scale handling. The fixes and cleanups are ordered ahead of the new interfaces so review of the latter does not block the former.