From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: S3 sleep in dom0 breaks dom0<->domU wallclock synchronization Date: Tue, 06 Jul 2010 01:03:12 +0200 Message-ID: <4C3264B0.5090605@invisiblethingslab.com> References: <4C322FF9.1050601@goop.org> <4C32602B.3090108@invisiblethingslab.com> <4C3261C8.4000808@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1208172153==" Return-path: In-Reply-To: <4C3261C8.4000808@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Keir Fraser , Rafal Wojtczuk , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1208172153== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig880D8DDAE71BEC50C0332311" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig880D8DDAE71BEC50C0332311 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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? >>> =20 >> Correct. I don't think DomU are notified in any way about system suspe= nd >> -- 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? >> =20 >=20 > 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? >=20 > 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 inventin= g > anything new. >=20 > I wonder if it makes sense to do a PV checkpoint-resume to PV domains o= n > host S3? >=20 >>> Does that affect all the guest clocks, or just wallclock? >>> >>> =20 >> Not sure if I understand your question -- what do you mean by "all gue= st >> clocks"? Like timers? They don't seem to be affected [*], as the apps >> run smoothly. >> =20 >=20 > I mean the other clocks you can real with clock_gettime(), such as > CLOCK_MONOTONIC or CLOCK_PROCESS_CPUTIME_ID, in addition to CLOCK_REALT= IME. >=20 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. --------------enig880D8DDAE71BEC50C0332311 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkwyZLAACgkQORdkotfEW84DCQCfc0Yg29mZ2hl4Oa9crggFxILG argAnjvZ/0yD4qP+x2xVNCrfPtX6foFL =yAvh -----END PGP SIGNATURE----- --------------enig880D8DDAE71BEC50C0332311-- --===============1208172153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1208172153==--