From patchwork Wed Jan 25 17:33:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Martins X-Patchwork-Id: 9537615 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 05B286042C for ; Wed, 25 Jan 2017 17:33:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EA93A2832B for ; Wed, 25 Jan 2017 17:33:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DF75C28334; Wed, 25 Jan 2017 17:33:36 +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 6D7032832B for ; Wed, 25 Jan 2017 17:33:36 +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 1cWRPd-0007YF-O3; Wed, 25 Jan 2017 17:31:13 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWRPc-0007XQ-NP for xen-devel@lists.xenproject.org; Wed, 25 Jan 2017 17:31:12 +0000 Received: from [85.158.143.35] by server-10.bemta-6.messagelabs.com id EA/1F-13192-0E0E8885; Wed, 25 Jan 2017 17:31:12 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeJIrShJLcpLzFFi42KZM10+UPf+g44 Igw+PRSy+b5nM5MDocfjDFZYAxijWzLyk/IoE1ozWy7NYCjZoVeycdpWlgbFDpYuRi0NIYCKT RMvbP8wQzm9GiQnH7zJCOBsZJbqWnGWDcBoZJaYcP8fUxcjJwSagJ9F6/jMziC0i4CDx8t0Ss A5mgV1MEqdWTwZLCAs4Slx+cYali5GDg0VAVeLB5kCQMK+Ap8TvS99YQWwJATmJ88d/gpVzCn hJ3N3ezAJiCwHVHJnXyw5RYyjxeeNS5gmMfAsYGVYxahSnFpWlFukaG+olFWWmZ5TkJmbm6Bo amOnlphYXJ6an5iQmFesl5+duYgQGCwMQ7GBsWhR4iFGSg0lJlPfUqY4IIb6k/JTKjMTijPii 0pzU4kOMMhwcShK8y+8D5QSLUtNTK9Iyc4BhC5OW4OBREuFVB0nzFhck5hZnpkOkTjHqcpy6c folkxBLXn5eqpQ470+QIgGQoozSPLgRsBi6xCgrJczLCHSUEE9BalFuZgmq/CtGcQ5GJWHePp ApPJl5JXCbXgEdwQR0xAXmdpAjShIRUlINjPbxUxZ+5Lq0vMXjVXjtmU3Ts29bMrwJe7Uj/sN FTSaZaAvLhCaHBOHA8Ofh/5wNp524O9f5gRe/2c5bfR+tQpwXHvumUdr7NW7reuGNp3czT3mS 2bj7QvqRO86bZGb5TUhYmtGzaPWbxE8xlxQUlWdPzFz61Oxap+27/bM3sb5cFnXxS9+/fkUll uKMREMt5qLiRABWhgYanAIAAA== X-Env-Sender: joao.m.martins@oracle.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1485365469!54400053!1 X-Originating-IP: [156.151.31.81] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 48099 invoked from network); 25 Jan 2017 17:31:11 -0000 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 25 Jan 2017 17:31:11 -0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0PHUuRS011483 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jan 2017 17:30:56 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0PHUukm014306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jan 2017 17:30:56 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v0PHUtSn016465; Wed, 25 Jan 2017 17:30:55 GMT Received: from paddy.lan (/89.114.92.174) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jan 2017 09:30:54 -0800 From: Joao Martins To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Date: Wed, 25 Jan 2017 17:33:05 +0000 Message-Id: <1485365586-21653-3-git-send-email-joao.m.martins@oracle.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1485365586-21653-1-git-send-email-joao.m.martins@oracle.com> References: <1485365586-21653-1-git-send-email-joao.m.martins@oracle.com> X-Source-IP: userv0022.oracle.com [156.151.31.74] Cc: Juergen Gross , x86@kernel.org, Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Boris Ostrovsky , Joao Martins Subject: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page 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 In order to support pvclock vdso on xen we need to setup the time info page for vcpu 0 and register the page with Xen using the VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall will also forcefully update the pvti which will set some of the necessary flags for vdso. Afterwards we check if it supports the PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having vdso/vsyscall support. And if so, it will set the cpu 0 pvti that will be later on used when mapping the vdso image. The xen headers are also updated to include the new hypercall for registering the secondary vcpu_time_info struct. Signed-off-by: Joao Martins --- Changes since RFC: (Comments from Boris and David) * Remove Kconfig option * Use get_zeroed_page/free/page * Remove the hypercall availability check * Unregister pvti with arg.addr.v = NULL if stable bit isn't supported. (New) * Set secondary copy on restore such that it works on migration. * Drop global xen_clock variable and stash it locally on xen_setup_vsyscall_time_info. * WARN_ON(ret) if we fail to unregister the pvti. --- arch/x86/xen/enlighten.c | 2 ++ arch/x86/xen/time.c | 51 ++++++++++++++++++++++++++++++++++++++++++++ arch/x86/xen/xen-ops.h | 1 + include/xen/interface/vcpu.h | 28 ++++++++++++++++++++++++ 4 files changed, 82 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 51ef952..15d271d 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -270,6 +270,8 @@ void xen_vcpu_restore(void) HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL)) BUG(); } + + xen_setup_vsyscall_time_info(0); } static void __init xen_banner(void) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 1e69956..e90f703 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -367,6 +367,56 @@ static const struct pv_time_ops xen_time_ops __initconst = { .steal_clock = xen_steal_clock, }; +int xen_setup_vsyscall_time_info(int cpu) +{ + struct pvclock_vsyscall_time_info *xen_clock; + struct vcpu_register_time_memory_area t; + struct pvclock_vcpu_time_info *pvti; + unsigned long addr; + u8 flags; + int ret; + + addr = get_zeroed_page(GFP_KERNEL); + if (!addr) + return -ENOMEM; + + xen_clock = (struct pvclock_vsyscall_time_info *) addr; + memset(xen_clock, 0, PAGE_SIZE); + + t.addr.v = &xen_clock->pvti; + + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, + cpu, &t); + + if (ret) { + pr_debug("xen: cannot register vcpu_time_info err %d\n", ret); + free_page(addr); + return ret; + } + + pvti = &xen_clock->pvti; + flags = pvti->flags; + + if (!(flags & PVCLOCK_TSC_STABLE_BIT)) { + t.addr.v = NULL; + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, + cpu, &t); + if (!ret) + free_page(addr); + + WARN_ON(ret); + pr_debug("xen: VCLOCK_PVCLOCK not supported\n"); + return -ENOTSUPP; + } + + pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT); + pvclock_set_pvti_cpu0_va(xen_clock); + + xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK; + + return 0; +} + static void __init xen_time_init(void) { int cpu = smp_processor_id(); @@ -393,6 +443,7 @@ static void __init xen_time_init(void) setup_force_cpu_cap(X86_FEATURE_TSC); xen_setup_runstate_info(cpu); + xen_setup_vsyscall_time_info(cpu); xen_setup_timer(cpu); xen_setup_cpu_clockevents(); diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index ac0a2b0..4036d15 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -66,6 +66,7 @@ void __init xen_vmalloc_p2m_tree(void); void xen_init_irq_ops(void); void xen_setup_timer(int cpu); void xen_setup_runstate_info(int cpu); +int xen_setup_vsyscall_time_info(int cpu); void xen_teardown_timer(int cpu); u64 xen_clocksource_read(void); void xen_setup_cpu_clockevents(void); diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h index 98188c8..8da788c 100644 --- a/include/xen/interface/vcpu.h +++ b/include/xen/interface/vcpu.h @@ -178,4 +178,32 @@ DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_vcpu_info); /* Send an NMI to the specified VCPU. @extra_arg == NULL. */ #define VCPUOP_send_nmi 11 + +/* + * Register a memory location to get a secondary copy of the vcpu time + * parameters. The master copy still exists as part of the vcpu shared + * memory area, and this secondary copy is updated whenever the master copy + * is updated (and using the same versioning scheme for synchronisation). + * + * The intent is that this copy may be mapped (RO) into userspace so + * that usermode can compute system time using the time info and the + * tsc. Usermode will see an array of vcpu_time_info structures, one + * for each vcpu, and choose the right one by an existing mechanism + * which allows it to get the current vcpu number (such as via a + * segment limit). It can then apply the normal algorithm to compute + * system time from the tsc. + * + * @extra_arg == pointer to vcpu_register_time_info_memory_area structure. + */ +#define VCPUOP_register_vcpu_time_memory_area 13 +DEFINE_GUEST_HANDLE_STRUCT(vcpu_time_info_t); +struct vcpu_register_time_memory_area { + union { + GUEST_HANDLE(vcpu_time_info_t) h; + struct pvclock_vcpu_time_info *v; + uint64_t p; + } addr; +}; +DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_time_memory_area_t); + #endif /* __XEN_PUBLIC_VCPU_H__ */