Re: [PATCH v32 0/5]Timestamp synchronization of host - guest tracing session

[Stefano De Venuto <stefano.devenuto99@gmail.com>]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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
>>>
>