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
