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 00:43:55 +0200 Message-ID: <4C32602B.3090108@invisiblethingslab.com> References: <4C322FF9.1050601@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1023222714==" Return-path: In-Reply-To: <4C322FF9.1050601@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 List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1023222714== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig60FFB06E1F1E3425E7120376" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60FFB06E1F1E3425E7120376 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/05/10 21:18, Jeremy Fitzhardinge wrote: > On 07/01/2010 09:12 AM, Keir Fraser wrote: >> On 01/07/2010 16:18, "Joanna Rutkowska" >> wrote: >> >> =20 >>> Actually we're running a pvops kernel in DomUs (in fact a fairly rece= nt >>> pvops0, as we had some bad experience with regular Fedora kernels in = DomU). >>> >>> Running an NTP in every VM is not a good solution. Some VMs might be >>> forbidden any access to the network (e.g. my "vault" VM, that I use f= or >>> storing passwords, and other very sensitive stuff, doesn't have any >>> networking), while some other might be allowed only very limited netw= ork >>> traffic, e.g. only HTTPS to specific, white-listed servers (e.g. >>> "banking" VM). >>> =20 >> Well it would be good to confirm first that this is a pv_ops domU issu= e. If >> so, it can probably be solved with a command-line option or somesuch, = even >> if the default policy will not change. >> =20 >=20 > So the problem is that dom0 does the S3 suspend/resume, and presumably > its wallclock time is updated properly via Linux's normal mechanisms. Yes. > 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? > Does that affect all the guest clocks, or just wallclock? >=20 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. joanna. [*] Except for when running on Core i5 -- see my other question in a different thread. --------------enig60FFB06E1F1E3425E7120376 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/ iEYEARECAAYFAkwyYCsACgkQORdkotfEW87QqQCfdUoZgn34D944ZuTLp/k0tLbs 5GkAoOwdZmPv5jQuXvHNc6OqcLRC+duv =MI0B -----END PGP SIGNATURE----- --------------enig60FFB06E1F1E3425E7120376-- --===============1023222714== 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 --===============1023222714==--