From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: S3 sleep in dom0 breaks dom0<->domU wallclock synchronization Date: Mon, 05 Jul 2010 16:19:52 -0700 Message-ID: <4C326898.6040709@goop.org> References: <4C322FF9.1050601@goop.org> <4C32602B.3090108@invisiblethingslab.com> <4C3261C8.4000808@goop.org> <4C3264B0.5090605@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C3264B0.5090605@invisiblethingslab.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Joanna Rutkowska Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Keir Fraser , Rafal Wojtczuk , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 07/05/2010 04:03 PM, Joanna Rutkowska wrote: > I guess all these other clocks have nothing to do with RTC/wallclock, > right? They are effectively just like any other system timers (they are > system timers), and they are updated by the timer interrupt and they > don't need RTC to be happy? So, I would say they are fine, just like all > the other timers, as otherwise I would expect DomUs to explode/hang > after resume. > CLOCK_MONOTONIC is directly derived from the Xen system time, so it will presumably pause while the machine is suspended. CLOCK_REALTIME is just the Xen system time with an offset added to make the normal Unix TOD; if the offset isn't updated after resume, then it will also not advance over the suspend. J