From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: GPLPV questions Date: Sat, 28 Dec 2013 11:56:30 +0000 Message-ID: <52BEBC6E.3000304@citrix.com> References: <511BA0D7.8070809@tiscali.it> <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au> <52BD862B.4080704@tiscali.it> <6035A0D088A63A46850C3988ED045A4B68566D03@BITCOM1.int.sbss.com.au> <52BE8CCD.1040701@tiscali.it> <6035A0D088A63A46850C3988ED045A4B685671E0@BITCOM1.int.sbss.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6035A0D088A63A46850C3988ED045A4B685671E0@BITCOM1.int.sbss.com.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: James Harper , "fantonifabio@tiscali.it" , xen-devel List-Id: xen-devel@lists.xenproject.org On 28/12/2013 09:49, James Harper wrote: >> Thanks for the reply. >> I don't know if is virtual or hardware clock to resync. >> When I do save/restore of windows domUs (with gplpv) inside domain on >> restore the domain users are unable to login until windows time will be >> updated. >> I also enabled ntp and tried to set very low time between every ntp >> check but however, it takes a long time to synchronize. >> I did a fast search on citrix pv and probably the time update is here: >> https://github.com/xenserver/win- >> xeniface/blob/master/src/win32stubagent/XService.cpp >> on finishSuspend function, there is this comment: /* We need to resync >> the clock when we recover from suspend/resume. */ > Looks like citrix pv usermode code makes a WMI call into the driver to get the time from xen, and then sets the time back in the usermode code. > > Not as straightforward as I might have thought. I don't have a WMI interface but any mechanism of talking to the driver is fine. From a quick look I can't see how the driver gets the clock from Xen though. > > James HVM guests get wallclock time from the shared info page, which awkwardly changes its exact location between a 32 and 64 bit domains. Up until recently, the Citrix Windows PV drivers still contained a hacked HVMPARAM, for which the set_hvmparam manually forced the shinfo size, and updated the wallclock. The latching of the shinfo size was fixed a long time ago, but there was still an outstanding bug that when Qemu stepped the domain wallclock on resume, the domain didn't see the updated time for a minute or so. At a first guess, I would say that http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=915a59f25c5eddd86bc2cae6389d0ed2ab87e69e should fix the problem. To the best of my knowledge, this was the very last of oustanding issues preventing our PV driver running correctly on xen-unstable. ~Andrew