On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote: > On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote: > > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ > > > of the host clock. > > > > That is pretty good. > > Yes. > > > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() - > > > guest_tsc) part ? > > > > Yes, it results in simpler code, doesn't create dependency on the > > dreaded kvmclock, and is the best we can currently do wrt. precision. Even if the PHC sync algorithm manages to detect that the clock read is incorrect, consider the following: Variability in the VM-entry code path, such as cache effects and interrupts would cause certain readings to be longer then the average (assuming an average where cache is hot). Using the TSC removes this variability, which can be large in case of non realtime guests, where you do: 1. kvm_hypercall. 2. read host realtime clock. 3. schedule out qemu-kvm vcpu. 4. schedule in qemu-kvm vcpu. So using the delta between read host realtime and ->gettime64 increases precision and decreases variability. > Sorry, unless i am misunderstanding how this works, it'll get the guest clock > 2us behind, which is something not wanted. > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, > this means Chrony will sync the guest clock to > > host realtime - 2us > > Is that correct? > -- 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
