Hi Steven, On Tue, Feb 26, 2019 at 6:24 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > Hi Ceco, > > I was walking Yordan down the code in the kernel to show him the ideas > I have about using kvm_exit as the trace event on the host side, when I > noticed that it's called *after* interrupts and preemption are enabled! > > This totally breaks the design, as it is not a reliable event, because > the process running the guest is likely to get an interrupt or > preempted before recording that event, which can cause a huge > difference. > 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. > 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. > > Thanks! > > -- Steve -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center
|