On Tue, Feb 26, 2019 at 8:15 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Tue, 26 Feb 2019 18:02:48 +0000 > Tzvetomir Stoyanov <tstoyanov@xxxxxxxxxx> wrote: > > > We performed a lot of tests with the current implementation (relying > > on the kvm_exit event), > > and the results are very accurate and consistent. Of course, there are > > probes with huge > > deviation, but these can be easily filtered. > > At least we now know why there were huge deviations :-) > > > > > > kvm_enter is fine, but the reason that kvm_exit is not, is because, in > > > order to record the reason for the exit, it needs to call into either > > > the Intel or AMD code (as they are different), and that is done after > > > interrupts and preemption are enabled. > > > > > > Instead, we can trace the function kvm_read_l1_tsc, which happens while > > > interrupts are still enabled. > > > > > > Would you be able to test with that function instead of using kvm_exit? > > > Also, if you still see a drift, try setting both trace clocks to > > > x86-tsc, and see if you still get a drift. > > > > Yes, I'll test with the kvm_read_l1_tsc function tomorrow. Is it > > related to x86-tsc > > clock only, or it should work with any clock ? I noticed that the > > drift does not depend > > on the clock, x86-tsc also drifts. > > > > No, it shouldn't be related, you can do them differently. > > Is it only your machine that has an drift, or do you see it on other > machines? We looked at Yordan's laptop, and it had shifts, but not a > drift. That is, it was off for a bit but then goes back. Not a drift, > but a shift between two deltas. Not sure why. I tested on my machine only (Intel), with different clocks. The drift is easily visible using KernelShark combo plots - at the trace start, both traces are synced with accuracy up to 1-2 us. At the trace end the desync is bigger, depending on the trace duration. > The fact that it drifts with x86-tsc clock bothers me, because the > guest and the host are using the same crystal. For there to be a drift, > the tsc of the guest needs to be using a different crystal than the > host. That is, two different clock sources for the TSC depending on if > the CPU is in the VM or in the host context. > > BTW, is your box Intel or AMD? > > Thanks, > > -- Steve -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center
|