Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp75733imm; Tue, 19 Jun 2018 16:15:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIM/+sYYPO2mv0hJ1tyg8l+V8dmppm01aqnTd3R90Rk39aZrYrPLLyj4i1l5ibvyvTaB1X8 X-Received: by 2002:a17:902:a989:: with SMTP id bh9-v6mr21373088plb.245.1529450112326; Tue, 19 Jun 2018 16:15:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529450112; cv=none; d=google.com; s=arc-20160816; b=Ef4Weagg5OmK3O6aFgCDpPpWYnzizxeheeH0STsPjZDs41lkgRWs0VTfqoXjulnUVd XQbBE2+muqgBnEd9W8YapIZhy7cTSJLM0olfc9Zq7nd9OfdVwsVpSgsvK1u/nlU3E/Cu Lle7PKUuAqM2jkOpEFAtdkxCO5cbA7b/NsdSTCgRKWRX4ALbFSJdOx6O0pBkUTey+Rpw L7DTiX79/63Cqqlu+0GPXEx9Uk2cWt9FdFWZj3cH6uZ7dc86cvqmIgMVKxm1a4IDT7nf Gb3BdfI6l8n9hlcDWNs1ZE8wc7zU3yQ8+XcAUWYIOcPeh6GlIZRdRUtCv1xaowAn50fY 7egg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=bg/8r7dUwVfGPUYG07Fgrm2q671XxMwUXv95Ebong3Y=; b=mfSBbpZT/FiS+7WhkRdC0HDxmUMAegfWiUUHBWuHfXapO0nPFyJir/mEcBSRbfdWVc dTbelshIuskxwTOvE1NcYCYjVReEf7ifE5SuQlvSAA7xwerWUnri7PB6A0Ry82rvFQQ4 OqCqp7ESIl8GFxERGH+IWf/jvRPsSRtevhhrmDBZcCw59rfkgDNBZ4f17uHD6ymltTRc 7/ooD4dC0aEtin0KvsqttyjAvAK82SWy4TlWcu9eZ5icbJ/uk9MgE8NH9HzDCAjT6PEN Srdcf5QQ4S1nhYNtdObdE4k0lDNt89hlMQH17SKAUWFZ1pXFzYSY9KXkmM+Kt8fX6J40 bNmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z63-v6si603361pgb.456.2018.06.19.16.14.57; Tue, 19 Jun 2018 16:15:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752121AbeFSXNc (ORCPT + 99 others); Tue, 19 Jun 2018 19:13:32 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:58538 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751003AbeFSXN2 (ORCPT ); Tue, 19 Jun 2018 19:13:28 -0400 Received: from p4fea482e.dip0.t-ipconnect.de ([79.234.72.46] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fVPoH-00052u-QP; Wed, 20 Jun 2018 01:13:14 +0200 Date: Wed, 20 Jun 2018 01:13:13 +0200 (CEST) From: Thomas Gleixner To: Pavel Tatashin cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux@armlinux.org.uk, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, john.stultz@linaro.org, sboyd@codeaurora.org, x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com, douly.fnst@cn.fujitsu.com, peterz@infradead.org, prarit@redhat.com, feng.tang@intel.com, pmladek@suse.com, gnomes@lxorguk.ukuu.org.uk Subject: Re: [PATCH v10 6/7] x86/paravirt: add active_sched_clock to pv_time_ops In-Reply-To: <20180615174204.30581-7-pasha.tatashin@oracle.com> Message-ID: References: <20180615174204.30581-1-pasha.tatashin@oracle.com> <20180615174204.30581-7-pasha.tatashin@oracle.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Jun 2018, Pavel Tatashin wrote: > Early boot clock might differ from the clock that is used later on, > therefore add a new field to pv_time_ops, that shows currently active > clock. If platform supports early boot clock, this field will be changed > to use that clock early in boot, and later will be replaced with the > permanent clock. I'm not seeing why this is required. If a hypervisor provides a sched_clock() override then it's not the kernels problem to make sure that it is usable. Thanks, tglx