Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti [off-list ref] wrote:

On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:

quoted

On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti [off-list ref] wrote:

quoted

I read the comment three more times and even dug through the git
history.  It seems like what you're saying is that, under certain
conditions (which arguably would be bugs in the core Linux timing
code),

I don't see that as a bug. Its just a side effect of reading two
different clocks (one is CLOCK_MONOTONIC and the other is TSC),
and using those two clocks to as a "base + offset".

As the comment explains, if you do that, can't guarantee monotonicity.

quoted

actually calling ktime_get_boot_ns() could be non-monotonic
with respect to the kvmclock timing.  But get_kvmclock_ns() isn't used
for VM timing as such -- it's used for the IOCTL interfaces for
updating the time offset.  So can you explain how my patch is
incorrect?

ktime_get_boot_ns() has frequency correction applied, while
reading masterclock + TSC offset does not.

So the clock reads differ.

Ah, okay, I finally think I see what's going on.  In the kvmclock data
exposed to the guest, tsc_shift and tsc_to_system_mul come from
tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from
CLOCK_BOOTTIME.  So the kvmclock and kernel clock drift apart at a
rate given by the frequency shift and then suddenly agree again every
time the pvclock data is updated.

Is there a reason to do it this way?