From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYdFU-00046h-0b for qemu-devel@nongnu.org; Mon, 20 Jun 2011 08:06:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYdFS-0004tA-PW for qemu-devel@nongnu.org; Mon, 20 Jun 2011 08:06:35 -0400 Received: from goliath.siemens.de ([192.35.17.28]:32278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYdFS-0004sx-Dm for qemu-devel@nongnu.org; Mon, 20 Jun 2011 08:06:34 -0400 From: Jan Kiszka Date: Mon, 20 Jun 2011 14:06:25 +0200 Message-Id: Subject: [Qemu-devel] [PATCH v2 0/3] Let RTC follow backward jumps of host clock immediately List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Anthony Liguori Cc: Zachary Amsden , Gleb Natapov Just noticed that this issue is still unfixed because my series was somehow forgotten. So I've rebased it over current master, refactored it to use the generic Notifier infrastructure and renamed it to "clock reset notifier" to avoid confusion with icount related "warping". Please review / apply before 0.15-rc0, it fixes a relevant issue. Original series description: 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. We identified that one prominent guest affected by this is Windows which relies on the periodic RTC interrupt for time keeping. This series address the issue 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 both with hwclock in a Linux guest and by monitoring the Windows clock 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): notifier: Pass data argument to callback qemu-timer: Introduce clock reset notifier mc146818rtc: Handle host clock resets hw/fw_cfg.c | 2 +- hw/mc146818rtc.c | 20 ++++++++++++++++++++ input.c | 2 +- migration.c | 12 ++++++------ notify.c | 4 ++-- notify.h | 4 ++-- qemu-timer.c | 29 ++++++++++++++++++++++++++++- qemu-timer.h | 5 +++++ ui/sdl.c | 2 +- ui/spice-core.c | 2 +- ui/spice-input.c | 4 ++-- ui/vnc.c | 4 ++-- usb-linux.c | 2 +- vl.c | 4 ++-- xen-all.c | 2 +- 15 files changed, 75 insertions(+), 23 deletions(-)