lkml.org 
[lkml]   [2017]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading callback
From
Date
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

\
 
 \ /
  Last update: 2017-09-27 14:17    [W:0.036 / U:2.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site