On 3/25/21 8:20 AM, Tzvetomir Stoyanov wrote: > Hi Stefano, > > On Sat, Mar 20, 2021 at 6:17 PM Stefano De Venuto > <stefano.devenuto99@xxxxxxxxx> wrote: >> >> >> On 3/20/21 7:25 AM, Tzvetomir Stoyanov wrote: >>> Hi Stefano, >>> >>> On Fri, Mar 19, 2021 at 7:44 PM Stefano De Venuto >>> <stefano.devenuto99@xxxxxxxxx> wrote: >>>> >>>> On 3/19/21 12:55 PM, Tzvetomir Stoyanov wrote: >>>>> Hi Stefano, >>>>> >>>>> On Fri, Mar 19, 2021 at 12:08 PM Stefano De Venuto >>>>> <stefano.devenuto99@xxxxxxxxx> wrote: >>>> Hi! >>>>>> The commands used to record are: >>>>>> >>>>>> Host: >>>>>> # trace-cmd record -C x86-tsc -e kvm:* -e msr:* -A tumbleweed:823 -e >>>>>> msr:* -C x86-tsc sleep 1 >>>>> The guest trace clock is set automatically as the host, so this >>>>> command should be enough: >>>>> # trace-cmd record -C x86-tsc -e kvm:* -e msr:* -A tumbleweed:823 -e >>>>> msr:* sleep 1 >>>>> >>>>>> Guest: >>>>>> # echo x86-tsc > /sys/kernel/tracing/trace_clock >>>>> There is no need to set manually the guest clock, it will be >>>>> overwritten by trace-cmd agent. >>>>> >>>> Thanks so much for the proper way to do it, really appreciated. >>>>>> If necessary, I can provide more info about my setup, or do more tests. >>>>> Yes, please can you send me both host and guest trace files ? >>>> Here are the trace files, host and guest respectively: >>>> >>>> - http://xenbits.xen.org/people/dariof/tracing-examples/kvm/sync-kvmclock/trace.dat >>>> - http://xenbits.xen.org/people/dariof/tracing-examples/kvm/sync-kvmclock/trace-tumbleweed.dat >>>> >>>>> Also, it will be useful to send me the content of the KVM debug files: >>>>> /sys/kernel/debug/kvm/<guest ID>/vcpu<*>/tsc-offset >>>> The guest has one vcpu (vcpu0) and the content of the file is: >>>> >>>> 255647917761327 >>> Looks like there is a scaling between host and guest clocks in your >>> setup, not just a simple offset. We did not test yet our >>> implementation with scaling, although both offset and scaling are part >>> of the calculations. That makes your use case very valuable for us, as >>> we have an opportunity to test it now. And yes, looks like we have a >>> bug here. >>> Please, when you have time, can you repeat again the tracing session >>> and send again both trace files + the content of the KVM debug files: >>> /sys/kernel/debug/kvm/<guest ID>/vcpu0/tsc-offset >>> /sys/kernel/debug/kvm/<guest ID>/vcpu0/tsc-scaling-ratio >>> I'm asking to do a new trace, as most probably these offset and >>> scaling could be different now. >> Yes, the trace files are attached to this mail. >> >> The content of tsc-offset is: >> 453568564244284 >> >> The content of tsc-scaling-ratio is: >> 4294967296 >> > Just submitted the v33 of the patch set, added a check for a > non-default KVM scaling. Now it should work on your setup, as the KVM > scaling there looks to be the default. I didn't test it, as we have no > machine which supports KVM scaling. This is just a workaround, we have > to implement support to KVM scaling in our algorithm. > Please, can you test if it is OK ? Note, you have to apply these > patch sets also, as there are dependencies: > v2 Refactoring and improvements of time sync logic > v4 TSC trace clock to nanosecond conversion > > Thanks for testing this code! I tested the patch series and now works properly on my setup! Thanks, Stefano > >> Thanks and Regards, >> >> Stefano >> >>> Thanks! >>> >>>>>> Thanks and Regards, >>>>>> >>>>>> Stefano >>>>> Thanks for testing this code! >>>>> >>>> Thanks for your time, >>>> >>>> Stefano >>> >