From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: syncing wall clock time from Dom0 to hypervisor Date: Wed, 13 Jul 2011 15:37:18 +0100 Message-ID: <4E1DBBAE0200007800072DE3@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1836455269==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: konrad.wilk@oracle.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1836455269== Content-Type: multipart/alternative; boundary="=__Part1837468E.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part1837468E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> Konrad Rzeszutek Wilk 07/13/11 3:52 PM >>> >Looking at xen_set_wallclock it just looks as we need to make it do >a similar hypercall as the sync_xen_wallclock to update it? I would think so. >I think the 'sync_cmos_clock' looks to be doing that. And the hook >to the Xen is via 'update_persistent_clock' call? The problem is that Xen code overwites the x86_platform.[gs]et_wallclock hooks, without calling (at least in the set case on Dom0) the original function afaics. Jan --=__Part1837468E.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML >>> Konrad Rzeszutek Wilk <konrad.wilk@oracl= e.com> 07/13/11 3:52 PM >>>
>Looking at xen_set_wallclock= it just looks as we need to make it do
>a similar hypercall as the = sync_xen_wallclock to update it?

I would think so.

>I = think the 'sync_cmos_clock' looks to be doing that. And the hook
>to = the Xen is via 'update_persistent_clock' call?

The problem is that = Xen code overwites the x86_platform.[gs]et_wallclock
hooks, without = calling (at least in the set case on Dom0) the original
function = afaics.

Jan
--=__Part1837468E.0__=-- --===============1836455269== 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 --===============1836455269==--