Re: [Xen-devel] GPLPV questions

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Sat, Dec 28, 2013 at 11:56:30AM +0000, Andrew Cooper wrote:
> 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.
> 

master commit 915a59f25c5eddd86bc2cae6389d0ed2ab87e69e (x86/time: Update 
wallclock in shared info when altering domain time offset)
seems to be already backported to xen-4.3 branch, and it's included in Xen 
4.3.1 release (but it's not yet in Xen 4.3.0).

Just for the sake of archives, if someone else is wondering about this..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel