Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752172AbdI0Okx (ORCPT ); Wed, 27 Sep 2017 10:40:53 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:16913 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751821AbdI0Okw (ORCPT ); Wed, 27 Sep 2017 10:40:52 -0400 Subject: Re: [PATCH v4 2/3] x86/xen/time: setup vcpu 0 time info page To: Joao Martins , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <20170927134623.3147-1-joao.m.martins@oracle.com> <20170927134623.3147-3-joao.m.martins@oracle.com> Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Juergen Gross , Andy Lutomirski From: Boris Ostrovsky Message-ID: Date: Wed, 27 Sep 2017 10:40:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170927134623.3147-3-joao.m.martins@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1745 Lines: 63 > +static void xen_setup_vsyscall_time_info(void) > +{ > + struct vcpu_register_time_memory_area t; > + struct pvclock_vsyscall_time_info *ti; > + struct pvclock_vcpu_time_info *pvti; > + int ret; > + > + pvti = &__this_cpu_read(xen_vcpu)->time; > + > + /* > + * We check ahead on the primary time info if this > + * bit is supported hence speeding up Xen clocksource. > + */ > + if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT)) > + return; > + > + pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT); Is it OK to have this flag set if anything below fails? (I can see in the changelog that apparently at some point I've asked about this at v1 but I can't remember/find what exactly it was) -boris > + > + ti = (struct pvclock_vsyscall_time_info *)get_zeroed_page(GFP_KERNEL); > + if (!ti) > + return; > + > + t.addr.v = &ti->pvti; > + > + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t); > + if (ret) { > + pr_notice("xen: VCLOCK_PVCLOCK not supported (err %d)\n", ret); > + free_page((unsigned long)ti); > + return; > + } > + > + /* > + * If the check above succedded this one should too since it's the > + * same data on both primary and secondary time infos just different > + * memory regions. But we still check it in case hypervisor is buggy. > + */ > + pvti = &ti->pvti; > + if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT)) { > + t.addr.v = NULL; > + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, > + 0, &t); > + if (!ret) > + free_page((unsigned long)ti); > + > + pr_notice("xen: VCLOCK_PVCLOCK not supported (tsc unstable)\n"); > + return; > + } > + > + xen_clock = ti; > + pvclock_set_pvti_cpu0_va(xen_clock); > + > + xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK; > +} > +