From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bruce Rogers" Subject: wallclock time for paravirtualized guests Date: Tue, 28 Mar 2006 10:17:36 -0500 Message-ID: <4428F0FE.092E.0048.1@novell.com> References: <4427F3EB.092E.0048.1@novell.com> <44282079.092E.0048.1@novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1536522739==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1536522739== Content-Type: multipart/alternative; boundary="=__PartD6F3B680.0__=" --=__PartD6F3B680.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The paravirtualized guests are offered wallclock time referenced to UTC only, while fully virtualized guests are given the option via the config file (localtime parameter) of starting with UTC time or local time. What would it take to optionally provide localtime to the paravirtualized guests as well? For a guest that launches assuming localtime as its time basis, then later deriving UTC from it based on configuration files, this is problematic, requiring some convolutions to how it handles time as it boots. Is there some place where we can insert a localtime offset into the start-of-day structure, or perhaps change the sharedinfo wallclock time to be either localtime or utc, depending on a localtime parameter in the config file, similar to what is done for fully virtualized guests? - Bruce Rogers --=__PartD6F3B680.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
The paravirtualized guests are offered wallclock time referenced to UTC only, while fully virtualized guests are given the option via the config file (localtime parameter) of starting with UTC time or local time.
What would it take to optionally provide localtime to the paravirtualized guests as well?
For a guest that launches assuming localtime as its time basis, then later deriving UTC from it based on configuration files, this is problematic, requiring some convolutions to how it handles time as it boots.
Is there some place where we can insert a localtime offset into the start-of-day structure, or perhaps change the sharedinfo wallclock time to be either localtime or utc, depending on a localtime parameter in the config file, similar to what is done for fully virtualized guests?
 
- Bruce Rogers
--=__PartD6F3B680.0__=-- --===============1536522739== 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 --===============1536522739==--