search for: master_kernel_ns

...lue) > > > > that was read on masterclock initialization. > > > > > > I don't see the problem. The masterclock data is updated here: > > > > > > host_tsc_clocksource = kvm_get_time_and_clockread( > > > &ka->master_kernel_ns, > > > &ka->master_cycle_now); > > > > > > kvm_get_time_and_clockread() gets those values from > > > do_monotonic_boot(), which, barring bugs, should cause > > > get_kvmclock_ns() to return exactly the same thing as > > &...

...lue) > > > > that was read on masterclock initialization. > > > > > > I don't see the problem. The masterclock data is updated here: > > > > > > host_tsc_clocksource = kvm_get_time_and_clockread( > > > &ka->master_kernel_ns, > > > &ka->master_cycle_now); > > > > > > kvm_get_time_and_clockread() gets those values from > > > do_monotonic_boot(), which, barring bugs, should cause > > > get_kvmclock_ns() to return exactly the same thing as > > &...

...dating the guest clock, we only update relative to (TSC value) > > that was read on masterclock initialization. > > I don't see the problem. The masterclock data is updated here: > > host_tsc_clocksource = kvm_get_time_and_clockread( > &ka->master_kernel_ns, > &ka->master_cycle_now); > > kvm_get_time_and_clockread() gets those values from > do_monotonic_boot(), which, barring bugs, should cause > get_kvmclock_ns() to return exactly the same thing as > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in...

...dating the guest clock, we only update relative to (TSC value) > > that was read on masterclock initialization. > > I don't see the problem. The masterclock data is updated here: > > host_tsc_clocksource = kvm_get_time_and_clockread( > &ka->master_kernel_ns, > &ka->master_cycle_now); > > kvm_get_time_and_clockread() gets those values from > do_monotonic_boot(), which, barring bugs, should cause > get_kvmclock_ns() to return exactly the same thing as > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in...

...d, 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. Yes. > Is there a reason to do it this way? Since pvclock updates which upda...

...d, 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. Yes. > Is there a reason to do it this way? Since pvclock updates which upda...

On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > For better or for worse, I'm trying to understand this code. So far, > I've come up with this patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > Is it correct, or am I missing some subtlety? The master

On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > For better or for worse, I'm trying to understand this code. So far, > I've come up with this patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > Is it correct, or am I missing some subtlety? The master

...f-day data). > > When updating the guest clock, we only update relative to (TSC value) > that was read on masterclock initialization. I don't see the problem. The masterclock data is updated here: host_tsc_clocksource = kvm_get_time_and_clockread( &ka->master_kernel_ns, &ka->master_cycle_now); kvm_get_time_and_clockread() gets those values from do_monotonic_boot(), which, barring bugs, should cause get_kvmclock_ns() to return exactly the same thing as ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather roundabout manner....

...nly update relative to (TSC value) > > > that was read on masterclock initialization. > > > > I don't see the problem. The masterclock data is updated here: > > > > host_tsc_clocksource = kvm_get_time_and_clockread( > > &ka->master_kernel_ns, > > &ka->master_cycle_now); > > > > kvm_get_time_and_clockread() gets those values from > > do_monotonic_boot(), which, barring bugs, should cause > > get_kvmclock_ns() to return exactly the same thing as > > ktime_get_boot_ns() + ka-&...

...oot_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?

...lock + 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. > > Yes. > > > Is there a reason to do it this way?...

> On Oct 4, 2018, at 12:31 PM, Peter Zijlstra <peterz at infradead.org> wrote: > > On Thu, Oct 04, 2018 at 07:00:45AM -0700, Andy Lutomirski wrote: >>> On Oct 4, 2018, at 1:11 AM, Peter Zijlstra <peterz at infradead.org> wrote: >>> >>>> On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: >>>> I was hoping to hear this

> On Oct 4, 2018, at 12:31 PM, Peter Zijlstra <peterz at infradead.org> wrote: > > On Thu, Oct 04, 2018 at 07:00:45AM -0700, Andy Lutomirski wrote: >>> On Oct 4, 2018, at 1:11 AM, Peter Zijlstra <peterz at infradead.org> wrote: >>> >>>> On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: >>>> I was hoping to hear this