From: Joanna Rutkowska <joanna@invisiblethingslab.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir.fraser@eu.citrix.com>,
Rafal Wojtczuk <rafal@invisiblethingslab.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: S3 sleep in dom0 breaks dom0<->domU wallclock synchronization
Date: Tue, 06 Jul 2010 11:12:07 +0200 [thread overview]
Message-ID: <4C32F367.2090302@invisiblethingslab.com> (raw)
In-Reply-To: <4C326898.6040709@goop.org>
[-- Attachment #1.1: Type: text/plain, Size: 914 bytes --]
On 07/06/10 01:19, Jeremy Fitzhardinge wrote:
> 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.
>
What is an easy way to dump all those clocks, like e.g. via some /proc
entry?
j.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-07-06 9:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-01 3:04 S3 sleep in dom0 breaks dom0<->domU wallclock synchronization Rafal Wojtczuk
2010-07-01 14:50 ` Keir Fraser
2010-07-01 14:51 ` Keir Fraser
2010-07-01 15:18 ` Joanna Rutkowska
2010-07-01 16:12 ` Keir Fraser
2010-07-05 19:18 ` Jeremy Fitzhardinge
2010-07-05 19:26 ` Keir Fraser
2010-07-05 22:43 ` Joanna Rutkowska
2010-07-05 22:50 ` Jeremy Fitzhardinge
2010-07-05 23:03 ` Joanna Rutkowska
2010-07-05 23:19 ` Jeremy Fitzhardinge
2010-07-06 9:12 ` Joanna Rutkowska [this message]
2010-07-06 16:17 ` Jeremy Fitzhardinge
2010-07-06 3:52 ` Keir Fraser
2010-07-06 9:10 ` Joanna Rutkowska
2010-07-06 10:02 ` Jan Beulich
2010-07-06 10:27 ` Joanna Rutkowska
2010-07-06 12:50 ` Keir Fraser
2010-07-06 14:09 ` Joanna Rutkowska
2010-07-08 14:06 ` Joanna Rutkowska
2010-07-06 14:53 ` Dan Magenheimer
2010-07-06 16:24 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C32F367.2090302@invisiblethingslab.com \
--to=joanna@invisiblethingslab.com \
--cc=Jeremy.Fitzhardinge@citrix.com \
--cc=jeremy@goop.org \
--cc=keir.fraser@eu.citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=rafal@invisiblethingslab.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.