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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 12/06/13 15:50, Konrad Rzeszutek Wilk wrote:
> 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.

What I saw on recent Linux kernels (I think it was 3.9) is that the
kernel switches the clocksource from Xen to another available
clocksource when it sees an unreasonable drift, so it is not such a big
problem with upstream kernels.


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