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
next prev 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).