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. 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
|