Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752639AbdI0JSt (ORCPT ); Wed, 27 Sep 2017 05:18:49 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:51566 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752292AbdI0JSr (ORCPT ); Wed, 27 Sep 2017 05:18:47 -0400 Date: Wed, 27 Sep 2017 11:18:37 +0200 (CEST) From: Thomas Gleixner To: Paolo Bonzini cc: Denis Plotnikov , rkrcmar@redhat.com, kvm@vger.kernel.org, john.stultz@linaro.org, mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org, x86@kernel.org, rkagan@virtuozzo.com, den@virtuozzo.com Subject: Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading callback In-Reply-To: <7b886c9f-70a7-951b-ff6f-f77f263754e7@redhat.com> Message-ID: References: <1504106628-172372-1-git-send-email-dplotnikov@virtuozzo.com> <1504106628-172372-2-git-send-email-dplotnikov@virtuozzo.com> <7b886c9f-70a7-951b-ff6f-f77f263754e7@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1312 Lines: 34 On Tue, 26 Sep 2017, Paolo Bonzini wrote: > However, if get_device_system_crosststamp ran with kvmclock or Hyper-V > clocksource, the two values stored by read_with_stamp would be > different, basically a (TSC, nanoseconds) pair. And that's exactly the problem. The cross time stamp infrastructure keeps the system clocksource (e.g. TSC) and the reference clock (e.g. ART) separate. There is enforcement that the two are coupled which I pointed out in the other mail, but conceptually they are different things and we are not going to change that and add voodoo callbacks which return different timestamps from different sources into the clocksource. So if you want to map kvmclock to the existing infrastructure then: device clock: maps to the hypervisor clock system reference clock: maps to REF_TSC system timekeeper clock: maps to TSC Even if REF_TSC and TSC are the same physically conceptually they are different. To make use of the existing infrastructure you have to provide means to capture HV clock and reference clock atomically. Thats probably something he hypervisor provides as a value pair HVCLOCK_NSEC, REF_TSC_VAL. And then you can correlate system time to HVCLOCK_NSEC via REF_TSC_VAL because that has a fixed ratio / offset to the system TSC. Thanks, tglx