[xen-unstable test] 18092: tolerable FAIL

[xen-unstable test] 18092: tolerable FAIL

[xen.org]

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 18090 never pass

version targeted for testing:
 xen                  e430510e5cbbfcdc1077739292def633e70fedea
baseline version:
 xen                  e430510e5cbbfcdc1077739292def633e70fedea

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.

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

[Jan Beulich]

>>> On 07.06.13 at 08:47, xen.org <ian.jackson@eu.citrix.com> 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

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

[Tim Deegan]

At 08:52 +0100 on 07 Jun (1370595174), Jan Beulich wrote:
> >>> On 07.06.13 at 08:47, xen.org <ian.jackson@eu.citrix.com> 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).

Hmm.  The calculation specified in the public header will work: it uses
plain subtraction on 64-bit unsigned integers.  So for once we can claim
that the ABI is documented on this point. :)  

But wait -- this is in an 'is_hvm_domain' block.  I thought PV drivers
in HVM guests used HVMOP_get_time rather than calculating NOW()
themselves, because they don't know the TSC offset.  Or is that only on
Windows, where the TSC is controlled by non-PV parts of the kernel?

Either way, fixing gtime_to_gtsc() to handle stime < 0 sounds right.

Tim.

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

[Jan Beulich]

>>> On 10.06.13 at 11:52, Tim Deegan <tim@xen.org> wrote:
> At 08:52 +0100 on 07 Jun (1370595174), Jan Beulich wrote:
>> >>> On 07.06.13 at 08:47, xen.org <ian.jackson@eu.citrix.com> 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).
> 
> Hmm.  The calculation specified in the public header will work: it uses
> plain subtraction on 64-bit unsigned integers.  So for once we can claim
> that the ABI is documented on this point. :)  
> 
> But wait -- this is in an 'is_hvm_domain' block.  I thought PV drivers
> in HVM guests used HVMOP_get_time rather than calculating NOW()
> themselves, because they don't know the TSC offset.  Or is that only on
> Windows, where the TSC is controlled by non-PV parts of the kernel?
> 
> Either way, fixing gtime_to_gtsc() to handle stime < 0 sounds right.

Actually, I don't think that would be the proper course of action -
I continue to think that this function should only be called with
non-negative (i.e. unsigned) deltas. Instead I think the caller should
take care of calling it with the negated stime, and then doing with
the result whatever is appropriate - the question was whether we
can assume that users can deal with the effectively underflowed
TSC stamp that wpuld result here. If, as you say, we take what the
public header has as ABI specification, then we can safely assume so.

Jan

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

[Tim Deegan]

At 11:11 +0100 on 10 Jun (1370862717), Jan Beulich wrote:
> >>> On 10.06.13 at 11:52, Tim Deegan <tim@xen.org> wrote:
> > At 08:52 +0100 on 07 Jun (1370595174), Jan Beulich wrote:
> >> >>> On 07.06.13 at 08:47, xen.org <ian.jackson@eu.citrix.com> 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).
> > 
> > Hmm.  The calculation specified in the public header will work: it uses
> > plain subtraction on 64-bit unsigned integers.  So for once we can claim
> > that the ABI is documented on this point. :)  
> > 
> > But wait -- this is in an 'is_hvm_domain' block.  I thought PV drivers
> > in HVM guests used HVMOP_get_time rather than calculating NOW()
> > themselves, because they don't know the TSC offset.  Or is that only on
> > Windows, where the TSC is controlled by non-PV parts of the kernel?
> > 
> > Either way, fixing gtime_to_gtsc() to handle stime < 0 sounds right.
> 
> Actually, I don't think that would be the proper course of action -
> I continue to think that this function should only be called with
> non-negative (i.e. unsigned) deltas. Instead I think the caller should
> take care of calling it with the negated stime, and then doing with
> the result whatever is appropriate

OK, that makes sense - I guess this is the only caller that would ever
need to handle negative offsets.

Tim.

> - the question was whether we
> can assume that users can deal with the effectively underflowed
> TSC stamp that wpuld result here. If, as you say, we take what the
> public header has as ABI specification, then we can safely assume so.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel