From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751906AbdB0Wpf (ORCPT ); Mon, 27 Feb 2017 17:45:35 -0500 Received: from merlin.infradead.org ([205.233.59.134]:53638 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751793AbdB0Wp1 (ORCPT ); Mon, 27 Feb 2017 17:45:27 -0500 Date: Mon, 27 Feb 2017 14:04:40 +0100 From: Peter Zijlstra To: Paolo Bonzini Cc: Wanpeng Li , Mike Galbraith , LKML , Ingo Molnar , Thomas Gleixner , Borislav Petkov Subject: Re: tip.today - scheduler bam boom crash (cpu hotplug) Message-ID: <20170227130440.GW6500@twins.programming.kicks-ass.net> References: <1484811069.17751.14.camel@gmx.de> <20170119101924.GJ6485@twins.programming.kicks-ass.net> <20170119133633.GB6536@twins.programming.kicks-ass.net> <20170227124349.GU6515@twins.programming.kicks-ass.net> <3e7c34e2-757b-19e9-f7e5-9bfaadd79e5d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e7c34e2-757b-19e9-f7e5-9bfaadd79e5d@redhat.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 27, 2017 at 01:50:29PM +0100, Paolo Bonzini wrote: > > > On 27/02/2017 13:43, Peter Zijlstra wrote: > > On Mon, Feb 27, 2017 at 08:30:11PM +0800, Wanpeng Li wrote: > > > >>> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > >>> index 2a5cafd..542710b 100644 > >>> --- a/arch/x86/kernel/kvmclock.c > >>> +++ b/arch/x86/kernel/kvmclock.c > >>> @@ -107,12 +107,12 @@ static inline void kvm_sched_clock_init(bool stable) > >>> { > >>> if (!stable) { > >>> pv_time_ops.sched_clock = kvm_clock_read; > >>> + clear_sched_clock_stable(); > >>> return; > >>> } > >>> > >>> kvm_sched_clock_offset = kvm_clock_read(); > >>> pv_time_ops.sched_clock = kvm_sched_clock_read; > >>> - set_sched_clock_stable(); > >> > >> This results in sched clock always unstable for kvm guest since there > >> is no invariant tsc cpuid bit exposed for kvm guest currently. > > > > What the heck is KVM_FEATURE_CLOCKSOURCE_STABLE_BIT / > > PVCLOCK_TSC_STABLE_BIT about then? > > It checks that all the bugs in the host have been ironed out, and that > the host itself supports invtsc. But what does it mean if that is not so? That is, will kvm_clock_read() still be stable even if !stable?