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 01:03:12 +0200 [thread overview]
Message-ID: <4C3264B0.5090605@invisiblethingslab.com> (raw)
In-Reply-To: <4C3261C8.4000808@goop.org>
[-- Attachment #1.1: Type: text/plain, Size: 1862 bytes --]
On 07/06/10 00:50, Jeremy Fitzhardinge wrote:
> On 07/05/2010 03:43 PM, Joanna Rutkowska wrote:
>>> But the S3 suspend/resume is unnoticed by all the domUs, so they don't
>>> know that an enormous amount of time has passed in an instant?
>>>
>> Correct. I don't think DomU are notified in any way about system suspend
>> -- at least nothing is in the dmesg/messages logs.
>>
>> BTW: wouldn't it be good to actually notify them? Consider e.g. DomU
>> that has some device assigned to it (say a NIC) -- if we emulated S3
>> suspend/resume for this DomU, there is a hope it would properly
>> suspend/reinitialize the NIC, wouldn't it?
>>
>
> I guess? That implies some kind of PV S3 suspend and resume event to
> feed into the dom U's device model. What does 2.6.18-xen do?
>
> As far as time goes, I think it makes most sense to try and resuse as
> much of the existing kernel machinery as possible, rather than inventing
> anything new.
>
> I wonder if it makes sense to do a PV checkpoint-resume to PV domains on
> host S3?
>
>>> Does that affect all the guest clocks, or just wallclock?
>>>
>>>
>> Not sure if I understand your question -- what do you mean by "all guest
>> clocks"? Like timers? They don't seem to be affected [*], as the apps
>> run smoothly.
>>
>
> I mean the other clocks you can real with clock_gettime(), such as
> CLOCK_MONOTONIC or CLOCK_PROCESS_CPUTIME_ID, in addition to CLOCK_REALTIME.
>
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.
joanna.
[-- 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-05 23:03 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 [this message]
2010-07-05 23:19 ` Jeremy Fitzhardinge
2010-07-06 9:12 ` Joanna Rutkowska
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=4C3264B0.5090605@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.