DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 378FFC057FAF
Subject: Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading
 callback
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Denis Plotnikov <dplotnikov@virtuozzo.com>, 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
References: <1504106628-172372-1-git-send-email-dplotnikov@virtuozzo.com>
 <1504106628-172372-2-git-send-email-dplotnikov@virtuozzo.com>
 <alpine.DEB.2.20.1709252322120.2418@nanos>
 <7b886c9f-70a7-951b-ff6f-f77f263754e7@redhat.com>
 <alpine.DEB.2.20.1709270946200.1945@nanos>
 <7f73ec16-7262-329c-d2c3-d5481142c370@redhat.com>
 <alpine.DEB.2.20.1709271339020.2027@nanos>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <52d6cc44-b065-93d8-a284-9e372033ba9c@redhat.com>
Date: Wed, 27 Sep 2017 14:14:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1709271339020.2027@nanos>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1372
Lines: 38

On 27/09/2017 13:53, Thomas Gleixner wrote:
>> I think the hook should be specific to x86.  For example it could be an
>> array of function pointers, indexed by vclock_mode, with the same
>> semantics as read_with_stamp.
> I don't think you need that.
> 
> The get_time_fn() which is handed in to get_device_system_crossstamp() can
> convey that information:
> 
>                 /*
>                  * Try to synchronously capture device time and a system
>                  * counter value calling back into the device driver
>                  */
>                 ret = get_time_fn(&xtstamp->device, &system_counterval, ctx);
>                 if (ret)
>                         return ret;
> 
> So in your case get_time_fn() would be kvmclock or hyperv clock specific
> and the actual hypercall implementation can return a failure code if the
> requirements are not met:
> 
>    1) host clock source is TSC
>    2) capturing of host time and TSC is atomic

So you are suggesting reusing the cross-timestamp hypercall to implement
nested pvclock.  There are advantages and disadvantages to that.

With read_with_stamp-like callbacks:

+ running on old KVM or on Hyper-V is supported
- pvclock_gtod_copy does not go away

With hypercall-based callbacks on the contrary:

+ KVM can use ktime_get_snapshot for the bare metal case
- only very new KVM is supported

Paolo