Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp738713ybj; Sat, 21 Sep 2019 10:53:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqyXz9UlZ625DxR+1siChSb1OFC7u6ZcwpUp+rvO/p77AJDP4dKUYwE3JNsTpgQyxldf7QMT X-Received: by 2002:a17:906:1385:: with SMTP id f5mr24069374ejc.145.1569088396639; Sat, 21 Sep 2019 10:53:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569088396; cv=none; d=google.com; s=arc-20160816; b=Za8pJizeKIr2V/D+6g+Utsg50E/M3kNv34V00edzt9PsYuzXE2NdEclQZKGJJHOpii Y8k0Cn0GRoqeqy5jqg3FIUTRmbrCO3i/gR1J5tl26M14aoBCAZbZth849AOjmvKVEjVy VRyDoRm54HrIu8DfTjkD6xXLlP4+URMWiMw78uznBhFwK0IqWt6hijReegxsivM8Jb7R 2Mr4qDngaX+uQhXRtiLhOZdUMmn4UnVHEKStF1g32IirRD9cdtuqV0RmlFUuqV3UaSBv mbAHacRz997YMXyX03W+ZJn+1YZqY6veFapOLkEWl8fBHBfn+ndQvdFQW7uZ2yzqwzjX qbsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=Nx/aQvRelzeLvCi79YG6MG8KeIQqwCv6VmFW22dXX5s=; b=SS3vljjGcXp8zpZZiYKiLSllBVPBzsjX3DF38iheHolMx/9NH8ejmw4cZIWQk6kHfb yKvMxAKdR8j11H+L/Pyux2KbMqs9hPKivx60FTkJYZe3bjlYBF+CF9/CC06hchzQa0uj nRwne5iRQNzN7PWETBPzPqFQ0gZVYYpXPKbGATg9cDy0W6OFuKSN6IEOkMJpguKeAai1 fcjsbkf+6bohaBWyNHJvq4dt56QSaHYAnZuN650pNwEwnN9vgMsTYde7L4+d+y0oSA/Q v6wjH/buftlYvZa2phwwGt3TswC6eFc0I9hpjvsWRAHVQKjH3xphOzccRjpP9nBAXfVr hg2A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h64si3853726edd.196.2019.09.21.10.52.53; Sat, 21 Sep 2019 10:53:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727825AbfITNdu (ORCPT + 99 others); Fri, 20 Sep 2019 09:33:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16433 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725842AbfITNdu (ORCPT ); Fri, 20 Sep 2019 09:33:50 -0400 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 28C303DE31 for ; Fri, 20 Sep 2019 13:33:50 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id a4so2303007wrg.8 for ; Fri, 20 Sep 2019 06:33:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Nx/aQvRelzeLvCi79YG6MG8KeIQqwCv6VmFW22dXX5s=; b=nJyjvuSQVSJmzkn10tG5ezJLnZBkHb9zT+vkaEhZXFMXoYhc0wVeoCLdDQpQocVyvS 0LJ8C0/5vaxhByFtmr0lsn2q5rKgY9b8rOiOZuJkU8srklLRfPMU4TbawYJVFPH2CX1f nFjcZ42dZurtA5GNGh841fQH3N4fgauXaxkhyV+gl2mh3yr0JICnR6UB04YzJ6FjY+Gv xEbfvULAtyux91sZHC4LeRlZYXUUuHmhGAEeWcNzlKefKldoq3hULU1VeFjgFAJaQSc5 jXA76M39+1M+raajCj4GZhS3srwk8k1MiJoZ/7udLq61DMo+NSw3kFkadOclTiT3UjJW Ki8A== X-Gm-Message-State: APjAAAX8hSu1NKXKxAyTzC72pgaUGoVLDIBV7gP4f7Y4hqoP+dGxdiuP zLTGK8h4lDQP3RFtlUxfOOpe2Vz8yLFrt2/L3xJhDXFppEy3q/Bagk//AG66Fjvae45CrQmOxqy e1WG7prEXbw7cjRvOzaU7kLIv X-Received: by 2002:a1c:608b:: with SMTP id u133mr3588938wmb.27.1568986428854; Fri, 20 Sep 2019 06:33:48 -0700 (PDT) X-Received: by 2002:a1c:608b:: with SMTP id u133mr3588918wmb.27.1568986428623; Fri, 20 Sep 2019 06:33:48 -0700 (PDT) Received: from vitty.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id c1sm1536496wmk.20.2019.09.20.06.33.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Sep 2019 06:33:48 -0700 (PDT) From: Vitaly Kuznetsov To: Suleiman Souhlal Cc: john.stultz@linaro.org, sboyd@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Suleiman Souhlal , pbonzini@redhat.com, rkrcmar@redhat.com, tglx@linutronix.de Subject: Re: [RFC 2/2] x86/kvmclock: Use host timekeeping. In-Reply-To: <20190920062713.78503-3-suleiman@google.com> References: <20190920062713.78503-1-suleiman@google.com> <20190920062713.78503-3-suleiman@google.com> Date: Fri, 20 Sep 2019 15:33:47 +0200 Message-ID: <87woe38538.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Suleiman Souhlal writes: > When CONFIG_KVMCLOCK_HOST_TIMEKEEPING is enabled, and the host > supports it, update our timekeeping parameters to be the same as > the host. This lets us have our time synchronized with the host's, > even in the presence of host NTP or suspend. > > When enabled, kvmclock uses raw tsc instead of pvclock. > > When enabled, syscalls that can change time, such as settimeofday(2) > or adj_timex(2) are disabled in the guest. > > Signed-off-by: Suleiman Souhlal > --- > arch/x86/Kconfig | 9 +++ > arch/x86/include/asm/kvmclock.h | 2 + > arch/x86/kernel/kvmclock.c | 127 +++++++++++++++++++++++++++++++- > kernel/time/timekeeping.c | 21 ++++++ > 4 files changed, 155 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 4195f44c6a09..37299377d9d7 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -837,6 +837,15 @@ config PARAVIRT_TIME_ACCOUNTING > config PARAVIRT_CLOCK > bool > > +config KVMCLOCK_HOST_TIMEKEEPING > + bool "kvmclock uses host timekeeping" > + depends on KVM_GUEST > + ---help--- > + Select this option to make the guest use the same timekeeping > + parameters as the host. This means that time will be almost > + exactly the same between the two. Only works if the host uses "tsc" > + clocksource. > + I'd also like to speak up against this config, it is confusing. In case the goal is to come up with a TSC-based clock for guests which will return the same as clock_gettime() on the host (or, is the goal to just have the same reading for all guests on the host?) I'd suggest we create a separate (from KVMCLOCK) clocksource (mirroring host timekeeper) and guests will be free to pick the one they like. -- Vitaly