Re: [Xen-devel] [xen-unstable test] 18092: tolerable FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.13 at 08:47, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> flight 18092 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/18092/ 
> 
> Failures :-/ but no regressions.
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore     fail pass in 
> 18090

So commit eb60be3dd870aecfa47bed1118069680389c15f7 ("x86:
don't pass negative time to gtime_to_gtsc()") caught something
here after the first reboot of the Windows install in the guest:

Jun  7 02:35:44.623032 (XEN) d2v0: bogus time -19766120 (offsets 
-362881846364/0)

(and many more instances of this during the following about 1.5 sec).

Looking at the involved code again, I realize that pl->stime_offset
gets set from calling get_s_time(), yet the calculation in
__update_vcpu_system_time() starts from
this_cpu(cpu_time).stime_local_stamp, which validly can be before
the value the initializing get_s_time() invocation returned. So stime
can validly be negative here, and calculating tsc_stamp based on
the flushed-to-zero stime value is incorrect (and we really ought to
set tsc_timestamp to a value wrapped downwards through zero -
question is whether all possible guest calculations would cope with
that - Linux'es clearly would).

Jan


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