Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock periodically

[David Woodhouse]

On Mon, 2023-10-02 at 17:53 -0700, Sean Christopherson wrote:
> 
> The two domains use the same "clock" (constant TSC), but different math to compute
> nanoseconds from a given TSC value.  For decently large TSC values, this results
> in CLOCK_MONOTONIC_RAW and kvmclock computing two different times in nanoseconds.

This is the bit I'm still confused about, and it seems to be the root
of all the other problems.

Both CLOCK_MONOTONIC_RAW and kvmclock have *one* job: to convert a
number of ticks of the TSC running at a constant known frequency, to a
number of nanoseconds.

So how in the name of all that is holy do they manage to get
*different* answers?

I get that the mult/shift thing carries some imprecision, but is that
all it is? Can't we ensure that the kvmclock uses the *same* algorithm,
precisely, as CLOCK_MONOTONIC_RAW?


> E.g. IIUC, your proposed patch to use a single RDTSC[*] eliminates the drift by
> undoing the CLOCK_MONOTONIC_RAW crap using the same TSC value on both the "add"
> and the "subtract", but the underlying train wreck of mixing time domains is
> still there.

> [*] https://lore.kernel.org/all/ee446c823002dc92c8ea525f21d00a9f5d27de59.camel@xxxxxxxxxxxxx

That one's different; those clock domains are *supposed* to be
divergent and the point in the PV wall clock information is to convey
the delta between the two. I just made it use the delta between the two
at a *given* moment, instead of calculating the difference between
*two* different times.

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