Re: GPLPV questions

[Andrew Cooper <andrew.cooper3@citrix.com>]

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