Displaying 6 results from an estimated 6 matches for "tgt_tsc_khz".
2018 Oct 11
2
[patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
...ncy 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.
Yes.
> Is there a reason to do it this way?
Since...
2018 Oct 11
2
[patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
...ncy 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.
Yes.
> Is there a reason to do it this way?
Since...
2018 Oct 08
2
[patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti at redhat.com> wrote:
> >
> > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti at redhat.com> wrote:
> > > >
> > > > On Thu, Oct 04, 2018
2018 Oct 08
2
[patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti at redhat.com> wrote:
> >
> > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti at redhat.com> wrote:
> > > >
> > > > On Thu, Oct 04, 2018
2018 Oct 09
0
[patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
...>
> 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?
2018 Oct 11
0
[patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
...> 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...