> > QEMU reads the clock at each host wakeup, but it cannot compensate if > > the guest OS requires a higher frequency than the host timer frequency. > > Having a 1 ms period is definitively better to be able to run a wide > > range of guest OSes. > > I was thinking that if the host is woken later than it intended > (e.g. after 2ms with setitimer; could be any amount with any syscall > due to other scheduling delays), then it could fake the timer chip > time it presents to the guest for a short while as if there wasn't > really a timing gap,
This isn't possible with the current system. Qemu uses host signals to interrupt itself, ie. to stop executing guest code and process pending interrupts. Thus the minimum available length of a "short delay" is bounded buy the signal latency that you're trying to compensate for. 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. Paul _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
