On Thu, May 27, 2010 at 10:21 PM, Paul Brook <p...@codesourcery.com> wrote: > >> >> Then the amount >> >> of CPU cycles between timer interrupts would increase and hopefully >> >> the guest can keep up. If the guest sleeps, time base could be >> >> accelerated to catch up with wall clock and then set back to 1:1 rate. >> > >> > Can't follow you ATM, sorry. What should be slowed down then? And how >> > precisely? >> >> I think vm_clock and everything that depends on vm_clock, also >> rtc_clock should be tied to vm_clock in this mode, not host_clock. > > The problem is more fundamental than that. There is no real correlation > between vm_clock and the amount of code executed by the guest, especially not > on timescales less than a second.
Can we measure (or at least estimate with higher accuracy than the tick IRQ delivery jitter) the amount of code executed, somehow? For example, add TSC sampling to all TB or KVM VCPU exit and load/store paths?
