xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Joao Martins <joao.m.martins@oracle.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v5 4/5] x86/time: implement PVCLOCK_TSC_STABLE_BIT
Date: Fri, 23 Sep 2016 11:42:46 +0100	[thread overview]
Message-ID: <1474627367-8185-5-git-send-email-joao.m.martins@oracle.com> (raw)
In-Reply-To: <1474627367-8185-1-git-send-email-joao.m.martins@oracle.com>

This patch proposes relying on host TSC synchronization and
passthrough to the guest, when running on a TSC-safe platform. On
time_calibration we retrieve the platform time in ns and the counter
read by the clocksource that was used to compute system time. We can
guarantee that on a platform with a constant and reliable TSC, that the
time read on vcpu B right after A is bigger independently of the VCPU
calibration error. Since pvclock time infos are monotonic as seen by any
vCPU set PVCLOCK_TSC_STABLE_BIT, which then enables usage of VDSO on
Linux.  IIUC, this is similar to how it's implemented on KVM. Add also a
comment regarding this bit changing and that guests are expected to
check this bit on every read.

Should note that I've yet to see time going backwards in a long running
test I ran for 2 weeks (in a dual socket machine), plus few other
tests I did on older platforms.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>

Changes since v4:
 - Remove blanks from flag assignment.
 - Added "Reviewed-by" from Jan Beulich.
 - Move nop_rendezvous introduction (and the mention in the commit
   message) into the patch introducing clocksource=tsc.
 [I kept the Reviewed-by as there was no functional change but rather only
  moving things out (as from discussion in the other patch). I wasn't sure
  if I should have kept it, so if it was a wrong assumption in the protocol,
  let me know.]

Changes since v3:
 - Do not adjust time_calibration_rendezvous_tail for nop_rendezvous and
 instead set cpu_time_stamp directly on the rendezvous function.
 - Move CPU Hotplug checks into patch 2
 - Add a commit and code comment regarding guests cope with this bit
   changing on hosts.
 - s/host_tsc_is_clocksource/clocksource_is_tsc

Changes since v2:
 - Add XEN_ prefix to pvclock flags.
 - Adapter time_calibration_rendezvous_tail to have the case of setting master
 tsc/stime and use it for the nop_rendezvous.
 - Removed hotplug CPU option that was added in v1
 - Prevent online of CPUs when clocksource is tsc.
 - Remove use_tsc_stable_bit, since clocksource is only used to seed
 values. So instead we test if hotplug is possible, and prevent clocksource=tsc
 to be used.
 - Remove 1st paragrah of commit message since the behaviour described
   no longer applies since b64438c.

Changes since v1:
 - Change approach to skip std_rendezvous by introducing a
   nop_rendezvous
 - Change commit message reflecting the change above.
 - Use TSC_STABLE_BIT only if cpu hotplug isn't possible.
 - Add command line option to override it if no cpu hotplug is
 intended.
---
 xen/arch/x86/time.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 128e653..d307d93 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -955,6 +955,14 @@ static void __update_vcpu_system_time(struct vcpu *v, int force)
     _u.tsc_timestamp = tsc_stamp;
     _u.system_time   = t->stamp.local_stime;
 
+    /*
+     * It's expected that domains cope with this bit changing on every
+     * pvclock read to check whether they can resort solely on this tuple
+     * or if it further requires monotonicity checks with other vcpus.
+     */
+    if ( clocksource_is_tsc() )
+        _u.flags |= XEN_PVCLOCK_TSC_STABLE_BIT;
+
     if ( is_hvm_domain(d) )
         _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-09-23 10:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23 10:42 [PATCH v5 0/5] x86/time: PVCLOCK_TSC_STABLE_BIT support Joao Martins
2016-09-23 10:42 ` [PATCH v5 1/5] x86/time: refactor init_platform_time() Joao Martins
2016-09-23 10:42 ` [PATCH v5 2/5] x86/time: refactor read_platform_stime() Joao Martins
2016-09-23 10:42 ` [PATCH v5 3/5] x86/time: implement tsc as clocksource Joao Martins
2016-09-23 14:58   ` Jan Beulich
2016-09-23 10:42 ` Joao Martins [this message]
2016-09-23 10:42 ` [PATCH v5 5/5] x86/time: extend "tsc" param with "stable:socket" Joao Martins
2016-09-23 15:00   ` Jan Beulich

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=1474627367-8185-5-git-send-email-joao.m.martins@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).