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
