Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3710562imm; Mon, 8 Oct 2018 08:20:18 -0700 (PDT) X-Google-Smtp-Source: ACcGV63AM5eFt3oEDHXWAJATr63Q7svekp4X8RlMCoxQEwxJx4R/PJHFEIaPGKIZiMg8c0KQKPdr X-Received: by 2002:a17:902:3143:: with SMTP id w61-v6mr24703040plb.85.1539012018383; Mon, 08 Oct 2018 08:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539012018; cv=none; d=google.com; s=arc-20160816; b=PEDX3DlMFvZ/fPdJM2AlhEsNIoTu5AxHnWCPJacX/5jz4zcJNSXG6CIkJIYOXXkw/h tEmzLnKQ/CwFfAJHAk8olOJx4J5yu15pJOXESUG3QyciGncQgO46ldRcjNnQczd5p3M/ WhttCcqZ00OmJ8tXznhlEDVSmKLyQ0h57yyeZrcnHKugkA6rkY7u4DFQH+0wGkJZKye9 I5NteXbc60FBlOP2ZBa6six1sGHxujDlCgO5iKN1pqyZKrpm1NDWYtSxbDfb3Ylkx4pI 3Zock4rau6rqXd7tMxk4A3Pd5Gwcc6CsUu3rXH3kx452A+hJTxuYgwDF1SDwdNggI70a ClRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=C+o6bHhKSRGzTowwi8gi4a1jRRFlY9qBiz81OW6k8fY=; b=mItv/1au6rA0xTMI/0NrjwfEgTSnHXuER+Y2cKJ6RHAu6diK9LWMWexKsH8Q/crmUl 4RAggiCKkgGeN3mb3LDbfU0EJxg+PJyNRRoljlCE3EuvYPIiqkzDSl6wLnb5PPvI9bH1 ssS29lAgnD+MUGcTv+Y614JMAM+smlR5Yn5gxGluwZvLIe6cq523CcsInpQtyPX6I1ux qFODVoZfevMX0+Utr9xpznX8Xx2EwqWCC1DVSgmVSz+EHb4uyxemKP7a5O4o5nMjKy+n F1xMgfWxrRUcsgqzbelEU6zl51u1akdrGprHq8xK79DojI0Y16N9AHRR3lcJ4B3/UshQ roGw== 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 i189-v6si19330114pfg.281.2018.10.08.08.20.02; Mon, 08 Oct 2018 08:20:18 -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 S1726439AbeJHWcB (ORCPT + 99 others); Mon, 8 Oct 2018 18:32:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58114 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbeJHWcA (ORCPT ); Mon, 8 Oct 2018 18:32:00 -0400 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 24BEF3097030; Mon, 8 Oct 2018 15:19:47 +0000 (UTC) Received: from amt.cnet (ovpn-112-5.gru2.redhat.com [10.97.112.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 135532016BE3; Mon, 8 Oct 2018 15:19:46 +0000 (UTC) Received: from amt.cnet (localhost [127.0.0.1]) by amt.cnet (Postfix) with ESMTP id C9EF0105144; Sat, 6 Oct 2018 17:49:55 -0300 (BRT) Received: (from marcelo@localhost) by amt.cnet (8.14.7/8.14.7/Submit) id w96Knd2T029932; Sat, 6 Oct 2018 17:49:39 -0300 Date: Sat, 6 Oct 2018 17:49:34 -0300 From: Marcelo Tosatti To: Andy Lutomirski Cc: Peter Zijlstra , Vitaly Kuznetsov , Thomas Gleixner , Paolo Bonzini , Radim Krcmar , Wanpeng Li , LKML , X86 ML , Matt Rickard , Stephen Boyd , John Stultz , Florian Weimer , KY Srinivasan , devel@linuxdriverproject.org, Linux Virtualization , Arnd Bergmann , Juergen Gross Subject: Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support Message-ID: <20181006204932.GA27822@amt.cnet> References: <20180914125006.349747096@linutronix.de> <87sh1ne64t.fsf@vitty.brq.redhat.com> <20181003190617.GC21381@amt.cnet> <87k1mycfju.fsf@vitty.brq.redhat.com> <20181004081100.GI19272@hirez.programming.kicks-ass.net> <20181004193150.GQ19272@hirez.programming.kicks-ass.net> <499807AB-E779-40C3-AA3F-E8C77A7770EC@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Mon, 08 Oct 2018 15:19:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > For better or for worse, I'm trying to understand this code. So far, > I've come up with this patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > Is it correct, or am I missing some subtlety? "In the non-fallback case, a bunch of gnarly arithmetic is done: a hopefully matched pair of (TSC, boot time) is read, then all locks are dropped, then the TSC frequency is read, a branch new multiplier and shift is read, and the result is turned into a time. This seems quite racy to me. Because locks are not held, I don't see what keeps TSC frequency used in sync with the master clock data." If tsc_khz changes, the host TSC clocksource will not be used, which disables masterclock: if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) || (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) { *lpj = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new); tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new); if (!(freq->flags & CPUFREQ_CONST_LOOPS)) mark_tsc_unstable("cpufreq changes"); In which case it ends up in: - spin_lock(&ka->pvclock_gtod_sync_lock); - if (!ka->use_master_clock) { - spin_unlock(&ka->pvclock_gtod_sync_lock); - return ktime_get_boot_ns() + ka->kvmclock_offset; - } masterclock -> non masterclock transition sets a REQUEST bit on each vCPU, so as to invalidate any previous clock reads. static void kvm_gen_update_masterclock(struct kvm *kvm) { #ifdef CONFIG_X86_64 int i; struct kvm_vcpu *vcpu; struct kvm_arch *ka = &kvm->arch; spin_lock(&ka->pvclock_gtod_sync_lock); kvm_make_mclock_inprogress_request(kvm); /* no guest entries from this point */ pvclock_update_vm_gtod_copy(kvm); kvm_for_each_vcpu(i, vcpu, kvm) kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu); /* guest entries allowed */ kvm_for_each_vcpu(i, vcpu, kvm) kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu); spin_unlock(&ka->pvclock_gtod_sync_lock); #endif /* * If the host uses TSC clock, then passthrough TSC as stable * to the guest. */ host_tsc_clocksource = kvm_get_time_and_clockread( &ka->master_kernel_ns, &ka->master_cycle_now); ka->use_master_clock = host_tsc_clocksource && vcpus_matched && !ka->backwards_tsc_observed && !ka->boot_vcpu_runs_old_kvmclock;