Re: [PATCH v5 04/34] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Tue, 2026-06-16 at 12:13 +0100, David Woodhouse wrote:
> On Mon, 2026-06-15 at 23:47 -0700, Dongli Zhang wrote:
> > I tested patches 02, 03, 04, and 26 by customizing QEMU to support kexec 
> > live
> > updates (LUO and KHO), preserving the memfd across kexec.
> 
> Thank you.
> 
> > For my use case, I used KVM_[GS]ET_CLOCK_GUEST instead of the existing
> > KVM_[GS]ET_CLOCK. I didn't account the downtime in my QEMU code, although 
> > host
> > TSC never resets across kexec.
> > 
> > Clock drift was zero, and I did not observe any unnecessary master clock 
> > updates
> > after KVM_SET_CLOCK_GUEST completed.
> 
> The kvmclock drift won't have been *zero*; it will have been a
> nanosecond or two. Which most people won't notice, but is annoying me.
> 
> It believe it comes from both pvclock_update_vm_gtod_copy() and
> kvm_vcpu_ioctl_set_clock_guest() rounding *down*. I think we should
> tweak the latter to round *up* so they're at least not biasing in the
> same direction.
> 
> We could also do better at picking a snapshot cycle count which
> *doesn't* lose in the rounding. But those are definitely improvements
> for another day; this series is long and complex enough and has already
> gained a dependency on fixes in core timekeeping snapshots.

I think some of that drift should be solved by the snapshot fixes from
https://lore.kernel.org/all/20260622211822.1056437-2-dwmw2@xxxxxxxxxxxxx/
and in fact we might be able to do even better...

Since ktime_get_snapshot_id() now calculates the ideal time with sub-
nanosecond precision, we would add that as a field in the snapshot and
then KVM could track ->master_clock_ns_frac and ->kvmclock_offset_frac
and eliminate the rest of the rounding error too.

It might be more trouble than it's worth, but either way I'll look at
it some other time; it can be done incrementally.

Attachment: smime.p7s
Description: S/MIME cryptographic signature