All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: asmetanin@virtuozzo.com, kvm@vger.kernel.org
Cc: Roman Kagan <rkagan@virtuozzo.com>,
	"Denis V. Lunev" <den@openvz.org>,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case
Date: Thu, 28 Jan 2016 16:53:31 +0100	[thread overview]
Message-ID: <56AA397B.4080209@redhat.com> (raw)
In-Reply-To: <56AA2AB6.3000802@redhat.com>



On 28/01/2016 15:50, Paolo Bonzini wrote:
> 
> 
> On 28/01/2016 15:25, Andrey Smetanin wrote:
>>>
>>>     Andrey, the test has a relative error of approximately 3 parts
>>>     per million on my machine.  In other words it drifts by 3
>>>     microseconds every second, which I don't think is acceptable.
>>>     The problem is that virtual_tsc_khz is 2593993 while the actual
>>>     frequency is more like 2594001 kHz.
>>>
>>>     But I have a problem in general with using tsc_khz to compute
>>>     the hyperv reference clock scale.  The maximum possible accuracy
>>>     on a 2.5 GHz machine is around 200 ppb, corresponding to a drift
>>>     of about 16 milliseconds per day.  Perhaps we could use Linux
>>>     (and kvmclock's) timekeeping parameters to derive the tsc_scale
>>>     and tsc_offset?
>>
>> Probably need to check the code. But can we just workaround it
>> by host periodic timer with period ~10ms which will issue(by scheduling
>> vcpu KVM_REQ_*) refresh of guest tsc page to prevent drifting?
> 
> That would kill performance.
> 
> However, after a bit more testing, kvmclock seems to have the same
> issue.  The formula to convert the kvmclock scale to the hyper-v one is
> 
> 	tsc_to_nsec_system_mul * 2^(32 + tsc_shift)/100
> 
> which on my system gives 0xFCA52ED99999999; that's within 0.1 ppb of
> what the Hyper-V code computes from a 2593993 kHz TSC.
> 
> So the patch seems okay, but we need to adjust kvm_guest_time_update to
> support the Hyper-V clock.  In kvm_guest_time_update we can compute a
> new scale and offset; if the scale changes, we set sequence to 0.  If
> the new offset is such that the clock would go backwards, we set
> sequence to 0.

... No, that doesn't work.  The clock would go backwards because the
TIME_REF_COUNT MSR is counting more slowly than the TSC-based clock.

I guess what we can do is to compute the TSC reference page parameters
as soon as the master clock is activated, and use them instead of
get_kernel_ns() to compute the reference count MSR (again if the master
clock is activated).  But I'm now a bit wary to enable the hyper-v TSC
reference page without knowing the effects of a divergence between the
two mechanisms.  Especially if a migration could lead to a switch from
one to the other and thus to the time going backwards.

Paolo

  reply	other threads:[~2016-01-28 15:53 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 14:04 [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case Paolo Bonzini
2016-01-28 14:04 ` Paolo Bonzini
2016-01-28 14:25 ` Andrey Smetanin
2016-01-28 14:50   ` Paolo Bonzini
2016-01-28 15:53     ` Paolo Bonzini [this message]
2016-01-28 18:45       ` Roman Kagan
2016-01-28 18:53     ` Roman Kagan
2016-01-28 21:28       ` Paolo Bonzini
2016-01-28 16:22 ` Roman Kagan
2016-02-03 16:37   ` Paolo Bonzini
2016-02-04  9:33     ` Roman Kagan
2016-02-04 10:13       ` Paolo Bonzini
2016-02-04 11:12         ` Roman Kagan
2016-04-21 17:01     ` Roman Kagan
2016-04-22 13:32       ` Roman Kagan
2016-04-22 18:08         ` Paolo Bonzini
2016-04-25  8:47           ` Roman Kagan
2016-04-26 10:34             ` Roman Kagan
2016-05-25 18:33               ` Roman Kagan
2016-05-26 14:47                 ` Roman Kagan
2016-05-29 22:34                 ` Marcelo Tosatti
2016-02-08 15:18 [PATCH 0/4] kvmclock: improve accuracy Paolo Bonzini
2016-02-08 15:18 ` [PATCH 1/4] KVM: x86: rename argument to kvm_set_tsc_khz Paolo Bonzini
2016-02-11 15:01   ` Marcelo Tosatti
2016-02-08 15:18 ` [PATCH 2/4] KVM: x86: rewrite handling of scaled TSC for kvmclock Paolo Bonzini
2016-02-11 15:23   ` Marcelo Tosatti
2016-02-08 15:18 ` [PATCH 3/4] KVM: x86: pass kvm_get_time_scale arguments in hertz Paolo Bonzini
2016-02-08 15:18 ` [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct Paolo Bonzini
2016-02-09 18:41   ` Owen Hofmann
2016-02-10 13:57     ` Paolo Bonzini
2016-02-16 13:48   ` Marcelo Tosatti
2016-02-16 14:25     ` Marcelo Tosatti
2016-02-16 16:59       ` Paolo Bonzini
2016-02-19 14:12         ` Marcelo Tosatti
2016-02-19 15:53           ` Paolo Bonzini
2016-02-16 14:00 ` [PATCH 0/4] kvmclock: improve accuracy Marcelo Tosatti
2016-08-31 14:13 [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case Roman Kagan
2016-09-01 16:07 ` Paolo Bonzini
2016-09-01 16:07 Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56AA397B.4080209@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=asmetanin@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=rkagan@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.