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.
>>> 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 18090So 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
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.
>>> 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
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 appropriateOK, 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