Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 19/02/2016 15:12, Marcelo Tosatti wrote:
> 
>> >  I need to check how often the timekeeper updates the parameters.
> I'd assume once every tick, the function is called (the notifier).
> 
> But you can optimize that away by only updating the TSC frequency
> when mult/shift are updated, which should be much rarer.

Yes, exactly.  That would still not be rate limiting.

But worst case it can be a lot of adjustments, up to HZ per second...

Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 19/02/2016 15:12, Marcelo Tosatti wrote:
> 
>> >  I need to check how often the timekeeper updates the parameters.
> I'd assume once every tick, the function is called (the notifier).
> 
> But you can optimize that away by only updating the TSC frequency
> when mult/shift are updated, which should be much rarer.

Yes, exactly.  That would still not be rate limiting.

But worst case it can be a lot of adjustments, up to HZ per second...

Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Marcelo Tosatti]

On Tue, Feb 16, 2016 at 05:59:57PM +0100, Paolo Bonzini wrote:
> 
> 
> On 16/02/2016 15:25, Marcelo Tosatti wrote:
> > On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote:
> >> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
> >>> When an NTP server is running, it may adjust the time substantially
> >>> compared to the "official" frequency of the TSC.  A 12 ppm change
> >>> sums up to one second per day.
> >>>
> >>> This already shows up if the guest compares kvmclock with e.g. the
> >>> PM timer.  It shows up even more once we add support for the Hyper-V
> >>> TSC page, because the guest expects it to be in sync with the time
> >>> reference counter; effectively the time reference counter is just a
> >>> slow path to access the same clock that is in the TSC page.
> >>>
> >>> Therefore, we want kvmclock to provide the host kernel's
> >>> ktime_get_boot_ns() value, at least if the master clock is active.
> >>> To do so, reverse-compute the host's "actual" TSC frequency from
> >>> pvclock_gtod_data and return it from kvm_get_time_and_clockread.
> >>
> >> Paolo,
> >>
> >> You'd have to generate an update to the guest structures as well, 
> >> to reflect the new {mult,shift} values calculated by the host. 
> >> Here:
> >>
> >> /* disable master clock if host does not trust, or does not
> >>  * use, TSC clocksource
> >>  */
> >> if (gtod->clock.vclock_mode != VCLOCK_TSC &&
> >> atomic_read(_guest_has_master_clock) != 0)
> >> queue_work(system_long_wq, _gtod_work);
> >>
> >> No?
> >>
> >> At first, i'm afraid this might be heavy, so it might be interesting
> >> to rate limit the update operation.
> >>
> > 
> > Paolo,
> > 
> > I suppose its not sufficient: 
> > 
> > 500ppm of 300 seconds = .0005*300 = 0.15 seconds.
> > 
> > Should aim at avoiding time backwards event in the following situation:
> > 
> > 
> > T1) t1_kvmclock_read = get_nanoseconds(); 
> > /* NTP correction to kernel clock = 500ppm */
> > /* TSC correction via mult,shift = 0ppm */
> > 
> > VM-exit, update kvmclock (or Hyper-V) clock data with 
> > new values 
> > 
> > T2) t2_kvmclock_read = get_nanoseconds();
> > /* NTP correction to kernel clock = 500ppm */
> > /* TSC correction via mult,shift = 500ppm */
> > 
> > 
> > So should not allow the host clock (or system_timestamp) to diverge 
> > from (TSC based calculation) more than the duration of the event:
> > 
> > VM-exit, update kvmclock (or Hyper-V) with new data.
> > 
> > To avoid t2_kvmclock_read < t1_kvmclock_read
> 
> If I don't do rate limiting, that would not be a problem I think. 

Correct.

>  The
> host timekeeper code should take care of updating the base timestamps
> (TSC and nanoseconds) in a way that doesn't cause a clock-goes-backwards
> event?

Yes.

>  I need to check how often the timekeeper updates the parameters.

I'd assume once every tick, the function is called (the notifier).

But you can optimize that away by only updating the TSC frequency
when mult/shift are updated, which should be much rarer.

(Note this issue is also a problem for Linux based kvmclock today).

> 
> Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Marcelo Tosatti]

On Tue, Feb 16, 2016 at 05:59:57PM +0100, Paolo Bonzini wrote:
> 
> 
> On 16/02/2016 15:25, Marcelo Tosatti wrote:
> > On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote:
> >> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
> >>> When an NTP server is running, it may adjust the time substantially
> >>> compared to the "official" frequency of the TSC.  A 12 ppm change
> >>> sums up to one second per day.
> >>>
> >>> This already shows up if the guest compares kvmclock with e.g. the
> >>> PM timer.  It shows up even more once we add support for the Hyper-V
> >>> TSC page, because the guest expects it to be in sync with the time
> >>> reference counter; effectively the time reference counter is just a
> >>> slow path to access the same clock that is in the TSC page.
> >>>
> >>> Therefore, we want kvmclock to provide the host kernel's
> >>> ktime_get_boot_ns() value, at least if the master clock is active.
> >>> To do so, reverse-compute the host's "actual" TSC frequency from
> >>> pvclock_gtod_data and return it from kvm_get_time_and_clockread.
> >>
> >> Paolo,
> >>
> >> You'd have to generate an update to the guest structures as well, 
> >> to reflect the new {mult,shift} values calculated by the host. 
> >> Here:
> >>
> >> /* disable master clock if host does not trust, or does not
> >>  * use, TSC clocksource
> >>  */
> >> if (gtod->clock.vclock_mode != VCLOCK_TSC &&
> >> atomic_read(_guest_has_master_clock) != 0)
> >> queue_work(system_long_wq, _gtod_work);
> >>
> >> No?
> >>
> >> At first, i'm afraid this might be heavy, so it might be interesting
> >> to rate limit the update operation.
> >>
> > 
> > Paolo,
> > 
> > I suppose its not sufficient: 
> > 
> > 500ppm of 300 seconds = .0005*300 = 0.15 seconds.
> > 
> > Should aim at avoiding time backwards event in the following situation:
> > 
> > 
> > T1) t1_kvmclock_read = get_nanoseconds(); 
> > /* NTP correction to kernel clock = 500ppm */
> > /* TSC correction via mult,shift = 0ppm */
> > 
> > VM-exit, update kvmclock (or Hyper-V) clock data with 
> > new values 
> > 
> > T2) t2_kvmclock_read = get_nanoseconds();
> > /* NTP correction to kernel clock = 500ppm */
> > /* TSC correction via mult,shift = 500ppm */
> > 
> > 
> > So should not allow the host clock (or system_timestamp) to diverge 
> > from (TSC based calculation) more than the duration of the event:
> > 
> > VM-exit, update kvmclock (or Hyper-V) with new data.
> > 
> > To avoid t2_kvmclock_read < t1_kvmclock_read
> 
> If I don't do rate limiting, that would not be a problem I think. 

Correct.

>  The
> host timekeeper code should take care of updating the base timestamps
> (TSC and nanoseconds) in a way that doesn't cause a clock-goes-backwards
> event?

Yes.

>  I need to check how often the timekeeper updates the parameters.

I'd assume once every tick, the function is called (the notifier).

But you can optimize that away by only updating the TSC frequency
when mult/shift are updated, which should be much rarer.

(Note this issue is also a problem for Linux based kvmclock today).

> 
> Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 16/02/2016 15:25, Marcelo Tosatti wrote:
> On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote:
>> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
>>> When an NTP server is running, it may adjust the time substantially
>>> compared to the "official" frequency of the TSC.  A 12 ppm change
>>> sums up to one second per day.
>>>
>>> This already shows up if the guest compares kvmclock with e.g. the
>>> PM timer.  It shows up even more once we add support for the Hyper-V
>>> TSC page, because the guest expects it to be in sync with the time
>>> reference counter; effectively the time reference counter is just a
>>> slow path to access the same clock that is in the TSC page.
>>>
>>> Therefore, we want kvmclock to provide the host kernel's
>>> ktime_get_boot_ns() value, at least if the master clock is active.
>>> To do so, reverse-compute the host's "actual" TSC frequency from
>>> pvclock_gtod_data and return it from kvm_get_time_and_clockread.
>>
>> Paolo,
>>
>> You'd have to generate an update to the guest structures as well, 
>> to reflect the new {mult,shift} values calculated by the host. 
>> Here:
>>
>> /* disable master clock if host does not trust, or does not
>>  * use, TSC clocksource
>>  */
>> if (gtod->clock.vclock_mode != VCLOCK_TSC &&
>> atomic_read(_guest_has_master_clock) != 0)
>> queue_work(system_long_wq, _gtod_work);
>>
>> No?
>>
>> At first, i'm afraid this might be heavy, so it might be interesting
>> to rate limit the update operation.
>>
> 
> Paolo,
> 
> I suppose its not sufficient: 
> 
> 500ppm of 300 seconds = .0005*300 = 0.15 seconds.
> 
> Should aim at avoiding time backwards event in the following situation:
> 
> 
> T1) t1_kvmclock_read = get_nanoseconds(); 
> /* NTP correction to kernel clock = 500ppm */
> /* TSC correction via mult,shift = 0ppm */
> 
> VM-exit, update kvmclock (or Hyper-V) clock data with 
> new values 
> 
> T2) t2_kvmclock_read = get_nanoseconds();
> /* NTP correction to kernel clock = 500ppm */
> /* TSC correction via mult,shift = 500ppm */
> 
> 
> So should not allow the host clock (or system_timestamp) to diverge 
> from (TSC based calculation) more than the duration of the event:
> 
> VM-exit, update kvmclock (or Hyper-V) with new data.
> 
> To avoid t2_kvmclock_read < t1_kvmclock_read

If I don't do rate limiting, that would not be a problem I think.  The
host timekeeper code should take care of updating the base timestamps
(TSC and nanoseconds) in a way that doesn't cause a clock-goes-backwards
event?  I need to check how often the timekeeper updates the parameters.

Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 16/02/2016 15:25, Marcelo Tosatti wrote:
> On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote:
>> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
>>> When an NTP server is running, it may adjust the time substantially
>>> compared to the "official" frequency of the TSC.  A 12 ppm change
>>> sums up to one second per day.
>>>
>>> This already shows up if the guest compares kvmclock with e.g. the
>>> PM timer.  It shows up even more once we add support for the Hyper-V
>>> TSC page, because the guest expects it to be in sync with the time
>>> reference counter; effectively the time reference counter is just a
>>> slow path to access the same clock that is in the TSC page.
>>>
>>> Therefore, we want kvmclock to provide the host kernel's
>>> ktime_get_boot_ns() value, at least if the master clock is active.
>>> To do so, reverse-compute the host's "actual" TSC frequency from
>>> pvclock_gtod_data and return it from kvm_get_time_and_clockread.
>>
>> Paolo,
>>
>> You'd have to generate an update to the guest structures as well, 
>> to reflect the new {mult,shift} values calculated by the host. 
>> Here:
>>
>> /* disable master clock if host does not trust, or does not
>>  * use, TSC clocksource
>>  */
>> if (gtod->clock.vclock_mode != VCLOCK_TSC &&
>> atomic_read(_guest_has_master_clock) != 0)
>> queue_work(system_long_wq, _gtod_work);
>>
>> No?
>>
>> At first, i'm afraid this might be heavy, so it might be interesting
>> to rate limit the update operation.
>>
> 
> Paolo,
> 
> I suppose its not sufficient: 
> 
> 500ppm of 300 seconds = .0005*300 = 0.15 seconds.
> 
> Should aim at avoiding time backwards event in the following situation:
> 
> 
> T1) t1_kvmclock_read = get_nanoseconds(); 
> /* NTP correction to kernel clock = 500ppm */
> /* TSC correction via mult,shift = 0ppm */
> 
> VM-exit, update kvmclock (or Hyper-V) clock data with 
> new values 
> 
> T2) t2_kvmclock_read = get_nanoseconds();
> /* NTP correction to kernel clock = 500ppm */
> /* TSC correction via mult,shift = 500ppm */
> 
> 
> So should not allow the host clock (or system_timestamp) to diverge 
> from (TSC based calculation) more than the duration of the event:
> 
> VM-exit, update kvmclock (or Hyper-V) with new data.
> 
> To avoid t2_kvmclock_read < t1_kvmclock_read

If I don't do rate limiting, that would not be a problem I think.  The
host timekeeper code should take care of updating the base timestamps
(TSC and nanoseconds) in a way that doesn't cause a clock-goes-backwards
event?  I need to check how often the timekeeper updates the parameters.

Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Marcelo Tosatti]

On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote:
> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
> > When an NTP server is running, it may adjust the time substantially
> > compared to the "official" frequency of the TSC.  A 12 ppm change
> > sums up to one second per day.
> > 
> > This already shows up if the guest compares kvmclock with e.g. the
> > PM timer.  It shows up even more once we add support for the Hyper-V
> > TSC page, because the guest expects it to be in sync with the time
> > reference counter; effectively the time reference counter is just a
> > slow path to access the same clock that is in the TSC page.
> > 
> > Therefore, we want kvmclock to provide the host kernel's
> > ktime_get_boot_ns() value, at least if the master clock is active.
> > To do so, reverse-compute the host's "actual" TSC frequency from
> > pvclock_gtod_data and return it from kvm_get_time_and_clockread.
> 
> Paolo,
> 
> You'd have to generate an update to the guest structures as well, 
> to reflect the new {mult,shift} values calculated by the host. 
> Here:
> 
> /* disable master clock if host does not trust, or does not
>  * use, TSC clocksource
>  */
> if (gtod->clock.vclock_mode != VCLOCK_TSC &&
> atomic_read(_guest_has_master_clock) != 0)
> queue_work(system_long_wq, _gtod_work);
> 
> No?
> 
> At first, i'm afraid this might be heavy, so it might be interesting
> to rate limit the update operation.
> 

Paolo,

I suppose its not sufficient: 

500ppm of 300 seconds = .0005*300 = 0.15 seconds.

Should aim at avoiding time backwards event in the following situation:


T1) t1_kvmclock_read = get_nanoseconds(); 
/* NTP correction to kernel clock = 500ppm */
/* TSC correction via mult,shift = 0ppm */

VM-exit, update kvmclock (or Hyper-V) clock data with 
new values 

T2) t2_kvmclock_read = get_nanoseconds();
/* NTP correction to kernel clock = 500ppm */
/* TSC correction via mult,shift = 500ppm */


So should not allow the host clock (or system_timestamp) to diverge 
from (TSC based calculation) more than the duration of the event:

VM-exit, update kvmclock (or Hyper-V) with new data.

To avoid t2_kvmclock_read < t1_kvmclock_read

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Marcelo Tosatti]

On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote:
> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
> > When an NTP server is running, it may adjust the time substantially
> > compared to the "official" frequency of the TSC.  A 12 ppm change
> > sums up to one second per day.
> > 
> > This already shows up if the guest compares kvmclock with e.g. the
> > PM timer.  It shows up even more once we add support for the Hyper-V
> > TSC page, because the guest expects it to be in sync with the time
> > reference counter; effectively the time reference counter is just a
> > slow path to access the same clock that is in the TSC page.
> > 
> > Therefore, we want kvmclock to provide the host kernel's
> > ktime_get_boot_ns() value, at least if the master clock is active.
> > To do so, reverse-compute the host's "actual" TSC frequency from
> > pvclock_gtod_data and return it from kvm_get_time_and_clockread.
> 
> Paolo,
> 
> You'd have to generate an update to the guest structures as well, 
> to reflect the new {mult,shift} values calculated by the host. 
> Here:
> 
> /* disable master clock if host does not trust, or does not
>  * use, TSC clocksource
>  */
> if (gtod->clock.vclock_mode != VCLOCK_TSC &&
> atomic_read(_guest_has_master_clock) != 0)
> queue_work(system_long_wq, _gtod_work);
> 
> No?
> 
> At first, i'm afraid this might be heavy, so it might be interesting
> to rate limit the update operation.
> 

Paolo,

I suppose its not sufficient: 

500ppm of 300 seconds = .0005*300 = 0.15 seconds.

Should aim at avoiding time backwards event in the following situation:


T1) t1_kvmclock_read = get_nanoseconds(); 
/* NTP correction to kernel clock = 500ppm */
/* TSC correction via mult,shift = 0ppm */

VM-exit, update kvmclock (or Hyper-V) clock data with 
new values 

T2) t2_kvmclock_read = get_nanoseconds();
/* NTP correction to kernel clock = 500ppm */
/* TSC correction via mult,shift = 500ppm */


So should not allow the host clock (or system_timestamp) to diverge 
from (TSC based calculation) more than the duration of the event:

VM-exit, update kvmclock (or Hyper-V) with new data.

To avoid t2_kvmclock_read < t1_kvmclock_read

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Marcelo Tosatti]

On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
> When an NTP server is running, it may adjust the time substantially
> compared to the "official" frequency of the TSC.  A 12 ppm change
> sums up to one second per day.
> 
> This already shows up if the guest compares kvmclock with e.g. the
> PM timer.  It shows up even more once we add support for the Hyper-V
> TSC page, because the guest expects it to be in sync with the time
> reference counter; effectively the time reference counter is just a
> slow path to access the same clock that is in the TSC page.
> 
> Therefore, we want kvmclock to provide the host kernel's
> ktime_get_boot_ns() value, at least if the master clock is active.
> To do so, reverse-compute the host's "actual" TSC frequency from
> pvclock_gtod_data and return it from kvm_get_time_and_clockread.

Paolo,

You'd have to generate an update to the guest structures as well, 
to reflect the new {mult,shift} values calculated by the host. 
Here:

/* disable master clock if host does not trust, or does not
 * use, TSC clocksource
 */
if (gtod->clock.vclock_mode != VCLOCK_TSC &&
atomic_read(_guest_has_master_clock) != 0)
queue_work(system_long_wq, _gtod_work);

No?

At first, i'm afraid this might be heavy, so it might be interesting
to rate limit the update operation.

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Marcelo Tosatti]

On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote:
> When an NTP server is running, it may adjust the time substantially
> compared to the "official" frequency of the TSC.  A 12 ppm change
> sums up to one second per day.
> 
> This already shows up if the guest compares kvmclock with e.g. the
> PM timer.  It shows up even more once we add support for the Hyper-V
> TSC page, because the guest expects it to be in sync with the time
> reference counter; effectively the time reference counter is just a
> slow path to access the same clock that is in the TSC page.
> 
> Therefore, we want kvmclock to provide the host kernel's
> ktime_get_boot_ns() value, at least if the master clock is active.
> To do so, reverse-compute the host's "actual" TSC frequency from
> pvclock_gtod_data and return it from kvm_get_time_and_clockread.

Paolo,

You'd have to generate an update to the guest structures as well, 
to reflect the new {mult,shift} values calculated by the host. 
Here:

/* disable master clock if host does not trust, or does not
 * use, TSC clocksource
 */
if (gtod->clock.vclock_mode != VCLOCK_TSC &&
atomic_read(_guest_has_master_clock) != 0)
queue_work(system_long_wq, _gtod_work);

No?

At first, i'm afraid this might be heavy, so it might be interesting
to rate limit the update operation.

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 09/02/2016 19:41, Owen Hofmann wrote:
> Hi,
> Should this patch change the condition in pvclock_gtod_notify?
> Currently it looks like we'll only request a masterclock update when
> tsc is no longer a good clocksource.

Yes, you're right.

Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Paolo Bonzini]

On 09/02/2016 19:41, Owen Hofmann wrote:
> Hi,
> Should this patch change the condition in pvclock_gtod_notify?
> Currently it looks like we'll only request a masterclock update when
> tsc is no longer a good clocksource.

Yes, you're right.

Paolo

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Owen Hofmann]

Hi,
Should this patch change the condition in pvclock_gtod_notify?
Currently it looks like we'll only request a masterclock update when
tsc is no longer a good clocksource.

On Mon, Feb 8, 2016 at 7:18 AM, Paolo Bonzini  wrote:
> When an NTP server is running, it may adjust the time substantially
> compared to the "official" frequency of the TSC.  A 12 ppm change
> sums up to one second per day.
>
> This already shows up if the guest compares kvmclock with e.g. the
> PM timer.  It shows up even more once we add support for the Hyper-V
> TSC page, because the guest expects it to be in sync with the time
> reference counter; effectively the time reference counter is just a
> slow path to access the same clock that is in the TSC page.
>
> Therefore, we want kvmclock to provide the host kernel's
> ktime_get_boot_ns() value, at least if the master clock is active.
> To do so, reverse-compute the host's "actual" TSC frequency from
> pvclock_gtod_data and return it from kvm_get_time_and_clockread.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/include/asm/kvm_host.h |  3 ++-
>  arch/x86/kvm/x86.c  | 46 
> +++--
>  2 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 7b5459982433..7dd6d55b4868 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -538,7 +538,7 @@ struct kvm_vcpu_arch {
>
> gpa_t time;
> struct pvclock_vcpu_time_info hv_clock;
> -   unsigned int hw_tsc_khz;
> +   u64 hv_clock_tsc_hz;
> struct gfn_to_hva_cache pv_time;
> bool pv_time_enabled;
> /* set guest stopped flag in pvclock flags field */
> @@ -731,6 +731,7 @@ struct kvm_arch {
>
> spinlock_t pvclock_gtod_sync_lock;
> bool use_master_clock;
> +   u64 master_tsc_hz;
> u64 master_kernel_ns;
> cycle_t master_cycle_now;
> struct delayed_work kvmclock_update_work;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e0bf8f10dc22..c99101d4cc5e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1580,7 +1580,16 @@ static inline u64 vgettsc(cycle_t *cycle_now)
> return v * gtod->clock.mult;
>  }
>
> -static int do_monotonic_boot(s64 *t, cycle_t *cycle_now)
> +static u64 pvclock_gtod_tsc_hz(void)
> +{
> +   struct pvclock_gtod_data *gtod = _gtod_data;
> +
> +u64 gtod_tsc_hz = 10ULL << gtod->clock.shift;
> +do_div(gtod_tsc_hz, gtod->clock.mult);
> +return gtod_tsc_hz;
> +}
> +
> +static int do_monotonic_boot(s64 *t, cycle_t *cycle_now, u64 *tsc_hz)
>  {
> struct pvclock_gtod_data *gtod = _gtod_data;
> unsigned long seq;
> @@ -1589,6 +1598,7 @@ static int do_monotonic_boot(s64 *t, cycle_t *cycle_now)
>
> do {
> seq = read_seqcount_begin(>seq);
> +   *tsc_hz = pvclock_gtod_tsc_hz();
> mode = gtod->clock.vclock_mode;
> ns = gtod->nsec_base;
> ns += vgettsc(cycle_now);
> @@ -1601,13 +1611,14 @@ static int do_monotonic_boot(s64 *t, cycle_t 
> *cycle_now)
>  }
>
>  /* returns true if host is using tsc clocksource */
> -static bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now)
> +static bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now,
> +  u64 *tsc_hz)
>  {
> /* checked again under seqlock below */
> if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC)
> return false;
>
> -   return do_monotonic_boot(kernel_ns, cycle_now) == VCLOCK_TSC;
> +   return do_monotonic_boot(kernel_ns, cycle_now, tsc_hz) == VCLOCK_TSC;
>  }
>  #endif
>
> @@ -1668,7 +1679,8 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
>  */
> host_tsc_clocksource = kvm_get_time_and_clockread(
> >master_kernel_ns,
> -   >master_cycle_now);
> +   >master_cycle_now,
> +   >master_tsc_hz);
>
> ka->use_master_clock = host_tsc_clocksource && vcpus_matched
> && !backwards_tsc_observed
> @@ -1713,7 +1725,8 @@ static void kvm_gen_update_masterclock(struct kvm *kvm)
>
>  static int kvm_guest_time_update(struct kvm_vcpu *v)
>  {
> -   unsigned long flags, tgt_tsc_khz;
> +   unsigned long flags;
> +   u64 tgt_tsc_hz;
> struct kvm_vcpu_arch *vcpu = >arch;
> struct kvm_arch *ka = >kvm->arch;
> s64 kernel_ns;
> @@ -1724,6 +1737,7 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
>
> kernel_ns = 0;
> host_tsc = 0;
> +   tgt_tsc_hz = 0;
>
> /*
>  * If the host uses TSC clock, then passthrough TSC as stable
> @@ -1734,20 +1748,22 @@ static int kvm_guest_time_update(struct kvm_vcpu 

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

[Owen Hofmann]

Hi,
Should this patch change the condition in pvclock_gtod_notify?
Currently it looks like we'll only request a masterclock update when
tsc is no longer a good clocksource.

On Mon, Feb 8, 2016 at 7:18 AM, Paolo Bonzini  wrote:
> When an NTP server is running, it may adjust the time substantially
> compared to the "official" frequency of the TSC.  A 12 ppm change
> sums up to one second per day.
>
> This already shows up if the guest compares kvmclock with e.g. the
> PM timer.  It shows up even more once we add support for the Hyper-V
> TSC page, because the guest expects it to be in sync with the time
> reference counter; effectively the time reference counter is just a
> slow path to access the same clock that is in the TSC page.
>
> Therefore, we want kvmclock to provide the host kernel's
> ktime_get_boot_ns() value, at least if the master clock is active.
> To do so, reverse-compute the host's "actual" TSC frequency from
> pvclock_gtod_data and return it from kvm_get_time_and_clockread.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/include/asm/kvm_host.h |  3 ++-
>  arch/x86/kvm/x86.c  | 46 
> +++--
>  2 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 7b5459982433..7dd6d55b4868 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -538,7 +538,7 @@ struct kvm_vcpu_arch {
>
> gpa_t time;
> struct pvclock_vcpu_time_info hv_clock;
> -   unsigned int hw_tsc_khz;
> +   u64 hv_clock_tsc_hz;
> struct gfn_to_hva_cache pv_time;
> bool pv_time_enabled;
> /* set guest stopped flag in pvclock flags field */
> @@ -731,6 +731,7 @@ struct kvm_arch {
>
> spinlock_t pvclock_gtod_sync_lock;
> bool use_master_clock;
> +   u64 master_tsc_hz;
> u64 master_kernel_ns;
> cycle_t master_cycle_now;
> struct delayed_work kvmclock_update_work;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e0bf8f10dc22..c99101d4cc5e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1580,7 +1580,16 @@ static inline u64 vgettsc(cycle_t *cycle_now)
> return v * gtod->clock.mult;
>  }
>
> -static int do_monotonic_boot(s64 *t, cycle_t *cycle_now)
> +static u64 pvclock_gtod_tsc_hz(void)
> +{
> +   struct pvclock_gtod_data *gtod = _gtod_data;
> +
> +u64 gtod_tsc_hz = 10ULL << gtod->clock.shift;
> +do_div(gtod_tsc_hz, gtod->clock.mult);
> +return gtod_tsc_hz;
> +}
> +
> +static int do_monotonic_boot(s64 *t, cycle_t *cycle_now, u64 *tsc_hz)
>  {
> struct pvclock_gtod_data *gtod = _gtod_data;
> unsigned long seq;
> @@ -1589,6 +1598,7 @@ static int do_monotonic_boot(s64 *t, cycle_t *cycle_now)
>
> do {
> seq = read_seqcount_begin(>seq);
> +   *tsc_hz = pvclock_gtod_tsc_hz();
> mode = gtod->clock.vclock_mode;
> ns = gtod->nsec_base;
> ns += vgettsc(cycle_now);
> @@ -1601,13 +1611,14 @@ static int do_monotonic_boot(s64 *t, cycle_t 
> *cycle_now)
>  }
>
>  /* returns true if host is using tsc clocksource */
> -static bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now)
> +static bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now,
> +  u64 *tsc_hz)
>  {
> /* checked again under seqlock below */
> if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC)
> return false;
>
> -   return do_monotonic_boot(kernel_ns, cycle_now) == VCLOCK_TSC;
> +   return do_monotonic_boot(kernel_ns, cycle_now, tsc_hz) == VCLOCK_TSC;
>  }
>  #endif
>
> @@ -1668,7 +1679,8 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
>  */
> host_tsc_clocksource = kvm_get_time_and_clockread(
> >master_kernel_ns,
> -   >master_cycle_now);
> +   >master_cycle_now,
> +   >master_tsc_hz);
>
> ka->use_master_clock = host_tsc_clocksource && vcpus_matched
> && !backwards_tsc_observed
> @@ -1713,7 +1725,8 @@ static void kvm_gen_update_masterclock(struct kvm *kvm)
>
>  static int kvm_guest_time_update(struct kvm_vcpu *v)
>  {
> -   unsigned long flags, tgt_tsc_khz;
> +   unsigned long flags;
> +   u64 tgt_tsc_hz;
> struct kvm_vcpu_arch *vcpu = >arch;
> struct kvm_arch *ka = >kvm->arch;
> s64 kernel_ns;
> @@ -1724,6 +1737,7 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
>
> kernel_ns = 0;
> host_tsc = 0;
> +   tgt_tsc_hz = 0;
>
> /*
>  * If the host uses TSC clock, then passthrough TSC as stable
> @@ -1734,20 +1748,22 @@ static