|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 150024: trouble: blocked/broken
flight 150024 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150024/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 <job status> broken build-arm64-xsm <job status> broken build-armhf <job status> broken build-arm64-xsm 4 host-install(4) broken REGR. vs. 149888 build-amd64 4 host-install(4) broken REGR. vs. 149888 build-armhf 4 host-install(4) broken REGR. vs. 149888 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen fe36a173d110fd792f5e337e208a5ed714df1536 baseline version: xen 0135be8bd8cd60090298f02310691b688d95c3a8 Last test of basis 149888 2020-04-30 09:00:53 Z 5 days Testing same since 149986 2020-05-05 01:24:46 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Wei Liu <wl@xxxxxxx> jobs: build-arm64-xsm broken build-amd64 broken build-armhf broken build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-libvirt blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-amd64 broken broken-job build-arm64-xsm broken broken-job build-armhf broken broken-step build-arm64-xsm host-install(4) broken-step build-amd64 host-install(4) broken-step build-armhf host-install(4) Not pushing. ------------------------------------------------------------ commit fe36a173d110fd792f5e337e208a5ed714df1536 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Apr 30 10:47:14 2020 +0100 x86/amd: Initial support for Fam19h processors Fam19h is very similar to Fam17h in these regards. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 0c9751b53c2ee135fd484a03fd47f3bb5fbe63b8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 4 11:54:35 2020 +0200 x86/HyperV: correct hv_hcall_page for xen.efi build Along the lines of what the not reverted part of 3c4b2eef4941 ("x86: refine link time stub area related assertion") did, we need to transform the absolute HV_HCALL_PAGE into the image base relative hv_hcall_page (or else there'd be no need for two distinct symbols). Otherwise mkreloc, as used for generating the base relocations of xen.efi, will spit out warnings like "Difference at .text:0009b74f is 0xc0000000 (expected 0x40000000)". As long as the offending relocations are PC relative ones, the generated binary is correct afaict, but if there ever was the absolute address stored, xen.efi would miss a fixup for it. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Wei Liu <wl@xxxxxxx> commit b0f666c569b8af6a51ab8aeec3664d6acd1abee9 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 4 11:53:42 2020 +0200 x86/EFI: correct section offsets in mkreloc diagnostics These are more helpful if they point at the address where the relocated value starts, rather than at the specific byte of the difference. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 17b997aa1edb9eb8d9bd1958457ff50927f46832 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Mon May 4 11:53:01 2020 +0200 x86/hap: be more selective with assisted TLB flush When doing an assisted flush on HAP the purpose of the on_selected_cpus is just to trigger a vmexit on remote CPUs that are in guest context, and hence just using is_vcpu_dirty_cpu is too lax, also check that the vCPU is running. Due to the lazy context switching done by Xen dirty_cpu won't always be cleared when the guest vCPU is not running, and hence relying on is_running allows more fine grained control of whether the vCPU is actually running. I've measured the time of the non-local branch of flush_area_mask inside the shim running with 32vCPUs over 100000 executions and averaged the result on a large Westmere system (80 ways total). The figures where fetched during the boot of a SLES 11 PV guest. The results are as follow (less is better): Non assisted flush with x2APIC: 112406ns Assisted flush without this patch: 820450ns Assisted flush with this patch: 8330ns While there also pass NULL as the data parameter of on_selected_cpus, the dummy handler doesn't consume the data in any way. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 8d928648fd816f97ba3ebe98ab5d4b4a7def58ff Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 4 11:51:47 2020 +0200 xenoprof: limit scope of types and #define-s Quite a few of the items are used by xenoprof.c only, so move them there to limit their visibility as well as the amount of re-building needed in case of changes. Also drop the inclusion of the public header there. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Wei Liu <wl@xxxxxxx> commit e83719b53a9be1c69033b3ded8051d47e3dadab8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 4 11:51:18 2020 +0200 xenoprof: drop unused struct xenoprof fields Both is_primary and domain_ready are only ever written to. Drop both fields and restrict structure visibility to just the one involved CU. While doing so (and just for starters) make "is_compat" properly bool. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Wei Liu <wl@xxxxxxx> commit 7f6a6e8c0a400d1a073b083fe0b7d25ef74b14e0 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 4 11:48:13 2020 +0200 xenoprof: adjust ordering of page sharing vs domain type setting Buffer pages should be shared with "ignored" or "active" guests only (besides, obviously, the primary profiling domain). Hence domain type should be set to "ignored" before unsharing from the primary domain (which implies even a previously "passive" domain may then access its buffers, albeit that's not very useful unless it gets promoted to "active" subsequently), i.e. such that no further writes of records to the buffer would occur, and (at least for consistency) also before sharing it (with the calling domain) from the XENOPROF_get_buffer path. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Wei Liu <wl@xxxxxxx> (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |