On Thu, Jun 09, 2016 at 12:27:10AM -0300, Marcelo Tosatti wrote: > Ok, its not feasible to keep both REF_CLOCK (MSR) and shared memory > (REF_PAGE) clocks in sync. Even if the frequency correction is the same > for both, the kernel updates monotonic clock differently than the > stated frequency that is: > > monotonic clock (advertised via vsyscall notifier to use mult/freq pair) != tsc*freq > > So the best solution IMO is to: > > reads of guest clock = max(shared memory clock, get_kernel_ns() + > kvmclock_offset) > > Where reads of guest clock include: 1) kvm_get_time_and_clockread > (updates to kvmclock areas), 2) rdmsr(REF_CLOCK). > > Unless someone has a better idea, Roman, can you update your patch to > include such solution? for kvm_get_time_and_clockread, can fast forward > kvmclock_offset so that > > kvmclock_offset + get_kernel_ns() = shared memory clock I'm not sure I understand what you mean. ->system_time in pvclock *is* assigned kernel_ns + kvmclock_offset, i.e. at the time kvm_get_time_and_clockread() runs they are in sync by definition. They can diverge later due to different whole number math applied. There's also a problem that there can be arbitrary amount of time between assigning the return value for guest's rdmsr and actually entering the guest to deliver that value. In general I'm starting to feel the shared memory clock is trying to provide stronger guarantees than really useful. E.g. there's no such thing as synchronous TSC between vCPUs in a virtual machine, so every guest assuming it is broken; in reality that means that every sane guest must tolerate certain violations of monotonicity when multiple CPUs are used for timekeeping. I wonder if this consideration can allow for some simplification of the paravirtual clock code... Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
