On Tue, 26 Sep 2017, Paolo Bonzini wrote: > However, if get_device_system_crosststamp ran with kvmclock or Hyper-V > clocksource, the two values stored by read_with_stamp would be > different, basically a (TSC, nanoseconds) pair. And that's exactly the problem. The cross time stamp infrastructure keeps the system clocksource (e.g. TSC) and the reference clock (e.g. ART) separate. There is enforcement that the two are coupled which I pointed out in the other mail, but conceptually they are different things and we are not going to change that and add voodoo callbacks which return different timestamps from different sources into the clocksource. So if you want to map kvmclock to the existing infrastructure then: device clock: maps to the hypervisor clock system reference clock: maps to REF_TSC system timekeeper clock: maps to TSC Even if REF_TSC and TSC are the same physically conceptually they are different. To make use of the existing infrastructure you have to provide means to capture HV clock and reference clock atomically. Thats probably something he hypervisor provides as a value pair HVCLOCK_NSEC, REF_TSC_VAL. And then you can correlate system time to HVCLOCK_NSEC via REF_TSC_VAL because that has a fixed ratio / offset to the system TSC. Thanks, tglx
