Messages in this thread | | | Subject | Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading callback | From | Paolo Bonzini <> | Date | Wed, 27 Sep 2017 14:14:45 +0200 |
| |
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
| |