Re: [Xen-devel] [PATCH] xen: fix initialization of wallclock time for PVHVM on migration

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Jun 11, 2013 at 04:45:29PM +0100, Keir Fraser wrote:
> On 11/06/2013 16:05, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:
> 
> > On 11/06/2013 15:16, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > 
> >>> Would it be OK to call
> >>> update_domain_wallclock_time unconditionally on
> >>> hvm_hypercall_page_initialise?
> >> 
> >> The primary question is - why is what we have not enough for you?
> >> In particular I would expect that the call from arch_set_info_guest()
> >> (for vCPU 0) should do what you want. Or wait, this is covering PV
> >> only. So yes, with the description change I would then withdraw my
> >> NACK - apparently no-one really used the shared info wall clock
> >> time in a HVM guest so far (or it going wrong post-resume wasn't
> >> noticed).
> >> 
> >> I would, however, prefer the if() immediately preceding the patch
> >> context to be pulled out past the domain_lock()ed region, convert it
> >> to switch(), and add your code. That was, eventual other post-
> >> processing for the various map spaces has a consistent, easily
> >> extensible home.
> > 
> > I apparently made a fix for this to work on initial boot of a 32-bit PVHVM
> > guest back in September (a change in hvmloader to not zero the wc fields in
> > shared_info). But I agree I now can't see why it works... But it surely does
> > as it was tested to do so by Konrad.
> > 
> > A bit more digging required...
> 
> Hmm I can't find any confirmation that my patch actually *did* work. :( I'm
> sure I remember testing it though!

I do remember that it did work. The issue was :
 Bug 14519356 - SYSTEM TIME DRIFTS DRASTICALLY FOR GUEST WITH UEK2 KERNEL AFTER 
MIGRATION 


 Easily reproduced using save.restore.
@ .
@ [root@localhost ~]# uname -a
@ Linux localhost.localdomain 2.6.39-300.7.0.el6uek.i686 #1 SMP Thu Sep 6
@ 12:47:30 EDT 2012 i686 i686 i386 GNU/Linux
@ [root@localhost ~]# date
@ Tue Sep 11 22:38:19 PDT 2012
@ [root@localhost ~]# uptime
@  09:24:43 up 15590 days, 17:16,  3 users,  load average: 2.75, 1.21, 0.47
@ [root@localhost ~]#
@ [root@localhost ~]# date
@ Mon Apr 14 09:24:51 PDT 1919
@ [root@localhost ~]# 

So the date went back to 1919.

.. and the reason was the the shared page (which is not re-inited by
the kernel) ends up with a large negative delta causing it to go back
in time.

> 
> My suggestion is we do indeed remove the inner if() in latch_shinfo_size().
> Ie. Call update_domain_wallclock_time() even if shinfo size has apparently
> not changed. 
> 
> We only latch shinfo size on hypercall page initialisation and on setup of
> the callback irq. They are start-of-day/resume operations, so removing the
> if() should have no bad side effect that I can see. If nothing else it
> should make this wallclock-field setup more robust.
> 
>  -- Keir
> 
> >  -- Keir
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 

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