On 27/09/2017 10:52, Thomas Gleixner wrote: > But there is no requirement that current clocksource is TSC. The > requirement is: > > The hardware reference clock, the one which can be captured atomically > with device clock (PTP, audio whatever), is the coupled clock of the > current timekeeping clocksource. Both have a fixed ratio and offset. > > That's completely independend of TSC. TSC/ART are a particular hardware > implementation which can use that infrastructure because they fulfil the > requirement. Ok, this helps. > So please stop these uninformed claims about brokeness and TSC > requirements. It was a question, not an uninformed claim. You answered the question now. > Instead please sit down and figure out whether your > particular use case of kvmclock/hyperv clock actually fit into that > functionality, i.e. whether you have > > 1) 'device time' > 2) 'system reference time' > 3) 'system time' > > where > > #1 and #2 can be captured atomically > > #2 and #3 are coupled clocks with a fixed ratio and offset > > If those requirements are fulfilled then you can simply use it as is and it > will give you CLOCK_MONOTONIC and CLOCK_REALTIME for the captured device > time. > > If your use case is different and does not fit into that picture then > please write it up clearly what you are trying to achieve and we can > discuss how to make it work w/o adding duct tape hackery. Yes, I understand better now why you consider read_with_stamp a hack. And it is---but I was confused and couldn't think of anything better. The definitions do fit KVM, and indeed there is ptp-kvm that does something very similar to what you describe in the other mail. We have: #1 is host time #2 is host TSC #3 is guest TSC We know that #2 and #3 have a fixed ratio and offset. The point is whether #1 and #2 can be captured atomically. For PTP-KVM, the host tells the guest; if capturing the two is impossible, it fails the hypercall and ioctl(PTP_SYS_OFFSET_PRECISE) fails too. Right now, the hypercall fails if the host clocksource is not the TSC clocksource, which is safe. These patches are about ascertaining whether #1 and #2 can be captured atomically in a more generic way. In the read_with_stamp case: - if it returns true, it gives an atomic reading of #1 and #2 - if it returns false, it gives a reading of #1 only. 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. Paolo
