Paul Brook wrote: > On Wednesday 26 April 2006 14:01, Jamie Lokier wrote: > > Paul Brook wrote: > > > One solution (which is also desirable for other reasons) is to > > > implement some form of guest cycle counting based on the > > > instructions actually executed. Then use that as the high-precision > > > timesource, and use some for of adaptive method to keep host and > > > guest clocks in sync. > > > > That's what I meant, expressed more clearly, except that I meant to > > count guest time based on the real time spent executing guest code, > > rather than counting individual instructions. Thanks! > > How do you propose doing that? It implies you have some way of interrupting > the guest after it has executed a small amount of guest code, where "small" > is less than the resolution+latency of host timer interrupts.
Hmm. I hadn't thought that through, but it still works. It doesn't matter if the guest runs, say, for 20ms before its next emulated 1kHz interrupt - so long as it's not dependent on values from the emulated timer chip after 1ms (or any other emulated device which reveals the time). If the guest does read a device which depends on the time, that's an opportunity to interrupt it. Otherwise, from the guest's view, it's just as if the emulated CPU got faster for a while with the interrupts perfectly timed. -- Jamie _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
