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! > > Thanks and Regards, > > Stefano > > > > > Thanks! > > > >>>> Thanks and Regards, > >>>> > >>>> Stefano > >>> Thanks for testing this code! > >>> > >> Thanks for your time, > >> > >> Stefano > > > > > -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center