Please take the following as a compliment: After four weeks of studying and refactoring the qemu code I found a second bug. The 1st one was a missing ne2000 register, the second one lets the rtc-clock loose ticks if the system is under load. Cool!
The author (Fabrice?) obviously did no want the timer to loose ticks and did some extra calls to the timer handler. See rtc_periodic_timer in mc146818rtc.c. Unfortunately this does not send interrupts to the VM multiple times. As consequence Windows showed the wrong time after a while. Until recently I used that behaviour for benchmarks! The more blocking IO calls and display updates prevented the timer from ticking at the right time the windows clock lost some seconds. While tuning my code I could simply measure my success by the number of lost seconds. Since Disk IO and even SDL (display updating) were made async the strange rtc-feature was of no more use. So I decided to remove it ... In vl.c we now should have the following code: 8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--- void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time) { QEMUTimer **pt, *t; qemu_del_timer(ts); if(ts->clock->type == QEMU_TIMER_VIRTUAL) { int64_t diff = expire_time - cpu_get_ticks(); if(diff < 0) expire_time += 1 - diff; } /* add the timer in the sorted list */ >8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--- I have tuned the timer and poll() a little bit and also SDL now runs completely in a thread of it's own (using the same thread layer as disk IO does). I am currently fine-tuning qemu so that heavy load on the VM or the host do not throttle the efficiency too much. Yours Juergen _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel