On Tue, 2026-08-04 at 16:38 -0700, Sean Christopherson wrote:
> On Sat, Aug 01, 2026, David Woodhouse wrote:
> > On Fri, 2026-07-31 at 16:24 -0700, Sean Christopherson wrote:
> > >
> > > > + /*
> > > > + * 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 ||
> > > > + user_tsc_hz > curr_tsc_hz + 1000) {
> > >
> > > I don't follow, why is KVM restricting what frequency userspace can set?
> >
> > 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
> permissive
> 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?The two operations have to be considered in isolation, at the time they happen. The KVM clock provides a y=mx+c relationship from TSC (x) to kvmclock (y), where the rate (m) depends on the TSC frequency. The KVM_SET_CLOCK_GUEST function provides an equivalent y=mx+c relationship, instructing the kernel to make them match. If the rates are the *same* then this is basically a case of adjusting the constant epoch (c) to make the two parallel lines coincide. If they *aren't* parallel, then what is KVM_SET_CLOCK_GUEST even asking for? I guess the kernel can adjust the guest's kvmclock so that it *intersects* the requested line at some point around now, but that really isn't what KVM_SET_CLOCK_GUEST exists for.
smime.p7s
Description: S/MIME cryptographic signature
