On 2010-12-17 15:58, Jan Kiszka wrote: > By default, we base the mc146818 RTC on the host clock (CLOCK_REALTIME). > This works fine if only the frequency of the host clock is tuned (e.g. > by NTP) or if it is set to a future time. However, if the host is tuned > backward, e.g. because NTP obtained the correct time after the guest was > already started or the admin decided to tune the local time, we see an > unpleasant effect in the guest: The RTC will stall for the period the > host clock is set back. > > This series tries to address the issue more gracefully. By detecting > those warps and providing a callback mechanism to device models, the > RTC is enabled to update its timers and register content immediately. > Tested successfully with a hwclock readout loop in a Linux guest while > fiddling with the host time. > > Note that if this kind of RTC adjustment is not wanted, the user is > still free to decouple the RTC from the host clock and base it on the > VM clock - just like before. > > Jan Kiszka (3): > qemu-timer: Consolidate qemu_get_clock and qemu_get_clock_ns > qemu-timer: Introduce warp callback > mc146818rtc: Handle host clock warps > > hw/mc146818rtc.c | 17 ++++++++++++ > qemu-timer.c | 77 > ++++++++++++++++++++++++++++++++++++++++++++---------- > qemu-timer.h | 5 +++ > 3 files changed, 85 insertions(+), 14 deletions(-) >
Ping? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
