From patchwork Fri Sep 23 10:42:46 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 9347883 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4796560B16 for ; Fri, 23 Sep 2016 10:43:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 365DC2AB0A for ; Fri, 23 Sep 2016 10:43:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2AFF92AB26; Fri, 23 Sep 2016 10:43:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0F04B2AB19 for ; Fri, 23 Sep 2016 10:43:38 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnNv6-0007zd-8V; Fri, 23 Sep 2016 10:41:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnNv5-0007yw-Ax for xen-devel@lists.xenproject.org; Fri, 23 Sep 2016 10:41:27 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 8F/0E-29579-6D605E75; Fri, 23 Sep 2016 10:41:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRWlGSWpSXmKPExsXSO6nOVfca29N wg81b2Cy+b5nM5MDocfjDFZYAxijWzLyk/IoE1oymc/OYCvZKVzw+vZm5gXGfWBcjF4eQQAeT xJat85ghnG+MEq/mTmPpYuQEcjYySvzvqIVINDJK3Jlxkh0kwSagJ9F6/jMziC0ioCRxb9VkJ pAiZoEORokv508xgSSEBZwk7ny4AFTEwcEioCqxdicHSJhXwEPi4sr1bCC2hICcxPnjP8HmcA p4Srxq+sQGsdhD4tWLHiaIGmOJvll9LBMY+RYwMqxi1ChOLSpLLdI1MtJLKspMzyjJTczM0TU 0MNbLTS0uTkxPzUlMKtZLzs/dxAgMlXoGBsYdjFNP+B1ilORgUhLlbdz3JFyILyk/pTIjsTgj vqg0J7X4EKMMB4eSBO9E1qfhQoJFqempFWmZOcCghUlLcPAoifBOAUnzFhck5hZnpkOkTjEqS onz+oEkBEASGaV5cG2wSLnEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZi3AGQKT2ZeCdz0V0 CLmYAWf7vzBGRxSSJCSqqBMa1YXHenhekeIX32qITrHH1zzjxY5xZ0Pk+HpeRwSbbsbs9vn27 5WPKIZmY1iF9gsdtUHMVhdjzwjLlQmsWKJs/GrhppodeTHu6YLF0TnHooeME1kb8rpjv+n70t /6/b47+Gj6dvPVYvdycxuXhy0q/7c2P3ccve3Hhj3Zv3bRVTJHXaQg/sUWIpzkg01GIuKk4EA J0SkeKPAgAA X-Env-Sender: joao.m.martins@oracle.com X-Msg-Ref: server-13.tower-31.messagelabs.com!1474627284!61700307!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12915 invoked from network); 23 Sep 2016 10:41:25 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-13.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 23 Sep 2016 10:41:25 -0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8NAfNuB026818 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2016 10:41:23 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8NAfNBr032556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2016 10:41:23 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8NAfNmh022369; Fri, 23 Sep 2016 10:41:23 GMT Received: from paddy.lan (/89.114.92.174) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2016 03:41:22 -0700 From: Joao Martins To: xen-devel@lists.xenproject.org Date: Fri, 23 Sep 2016 11:42:46 +0100 Message-Id: <1474627367-8185-5-git-send-email-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1474627367-8185-1-git-send-email-joao.m.martins@oracle.com> References: <1474627367-8185-1-git-send-email-joao.m.martins@oracle.com> X-Source-IP: aserv0021.oracle.com [141.146.126.233] Cc: Andrew Cooper , Joao Martins , Jan Beulich Subject: [Xen-devel] [PATCH v5 4/5] x86/time: implement PVCLOCK_TSC_STABLE_BIT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper 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;