Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration
Sean Christopherson <[email protected]> Tue, 4 Aug 2026 16:38:17 -0700
| Newsgroups | gmane.linux.kernel,gmane.comp.emulators.kvm.devel,gmane.linux.documentation,gmane.comp.emulators.xen.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Aug 01, 2026, David Woodhouse wrote:
> On Fri, 2026-07-31 at 16:24 -0700, Sean Christopherson wrote:
> >=20
> > > + /*
> > > + * Allow for a discrepancy of 1 kHz either way between the TSC
> > > + * frequency used to generate the user's pvclock and the current
> > > + * host's measured frequency, since they may not precisely match.
> > > + */
> > > + if (user_tsc_hz < curr_tsc_hz - 1000 ||
> > > + =C2=A0=C2=A0=C2=A0 user_tsc_hz > curr_tsc_hz + 1000) {
> >=20
> > I don't follow, why is KVM restricting what frequency userspace can set=
?
>=20
> Userspace actually sets the frequency with KVM_SET_TSC_KHZ. What KVM is
> insisting upon here is that the input to KVM_SET_CLOCK_GUEST is
> *consistent* with the guest's TSC frequency (within a little slop
> caused by different host TSCs).
Why does KVM care though? I know some people hate that KVM's uAPI is permi=
ssive
to a fault, but trying to "help" userspace often ends badly for everyone. =
E.g.
what happens if userspace does KVM_SET_TSC_KHZ after KVM_SET_CLOCK_GUEST?