|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 102713: regressions - trouble: blocked/broken/pass
flight 102713 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/102713/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 102693 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12 migrate-support-check fail never pass version targeted for testing: xen 3a782c76036063e9b654fb54e952211ddc1e38f6 baseline version: xen 99a10da1b4fee8ef7a096e5fd3608f6c15932eb0 Last test of basis 102693 2016-11-28 09:01:45 Z 1 days Testing same since 102713 2016-11-29 16:01:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Dario Faggioli <dario.faggioli@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Stefano Stabellini <sstabellini@xxxxxxxxxx> Wei Chen <Wei.Chen@xxxxxxx> jobs: build-amd64 pass build-armhf broken build-amd64-libvirt pass test-armhf-armhf-xl blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ 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 Not pushing. ------------------------------------------------------------ commit 3a782c76036063e9b654fb54e952211ddc1e38f6 Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Tue Nov 29 16:01:03 2016 +0100 credit2: make runqueues be per-socket by default Benchmarks have shown that per-socket runqueues arrangement behaves better (e.g., we achieve better load balancing) than the current per-core default. Here's an example (coming from https://lists.xen.org/archives/html/xen-devel/2016-06/msg02287.html ): |=======================================| | XEN BUILD TIME, LOW LOAD, NO NOISE | |---------------------------------------| | runq=core runq=socket | | 35.200 33.433 | |---------------------------------------|------------------------------| | XEN BUILD TIME, HIGH LOAD, NO NOISE | IPERF, HIGH LOAD, NO NOISE | |---------------------------------------|------------------------------| | runq=core runq=socket | runq=core runq=socket | | 18.013 18.530 | 23.200 23.466 | |---------------------------------------|------------------------------| | XEN BUILD TIME, LOW LOAD, WITH NOISE | |------------------------------------- | | runq=core runq=socket | | 45.866 39.493 | |---------------------------------------|------------------------------| | XEN BUILD TIME, HIGH LOAD, WITH NOISE | IPERF, HIGH LOAD, WITH NOISE | |---------------------------------------|------------------------------| | runq=core runq=socket | runq=core runq=socket | | 36.840 29.080 | 19.967 21.000 | |=======================================|==============================| The only reason why we went for per-core, initially, was to introduce some form of hyperthreading support. Now we have hyperthreading support, independently from how runqueues are organized (9bb9c7388 "xen: credit2: implement true SMT support"), and thus we can switch to per-socket. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit d066b5b9ba8ca60b39127b3c9b1cd62a52307174 Author: Julien Grall <julien.grall@xxxxxxx> Date: Tue Nov 29 16:00:48 2016 +0100 libacpi: fix compilation when cross building the tools The tools (such as mk_dsdt) can be cross-built when it may not be desirable to build them on the target. The commit c4ac1077 "libxl/arm: Generate static ACPI DSDT table" introduced support of ARM64 in mk_dsdt but also break cross-building tools because the ACPI tables are not correct. While mk_dsdt should generate ACPI table for the target architecture, it currently generates the one for the host. This is because the source code contains reference to the host architecture (__aarch64__, __x86_64__, __i386__) when it should be the target architecture. Replace all __aarch64__, __x86_64__, __i386__ by the corresponding CONFIG_*. Also expose the CONFIG_* to the source code as the currently only exposed to the Makefile. Reported-by: Andrii Anisov <andrii.anisov@xxxxxxxxx> Suggested-by: Wei Liu <wei.liu2@xxxxxxxxxx> Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 6aaff7b407ca76dcfc4fe81f2afe9d1594cb0d6b Author: Wei Chen <Wei.Chen@xxxxxxx> Date: Tue Nov 29 15:59:55 2016 +0100 arm32: handle async aborts delivered while at HYP If guest generates an asynchronous abort and then traps into HYP (by HVC or IRQ) before the abort has been delivered, the hypervisor could not catch it, because the PSTATE.A bit is masked all the time in hypervisor. So this asynchronous abort may be slipped to next running guest with PSTATE.A bit unmasked. In order to avoid this, it is necessary to take the abort at HYP, by clearing the PSTATE.A bit. In this patch, we unmask the PSTATE.A bit to open a window to catch guest-generated asynchronous abort in all Guest -> HYP switch paths. If we caught such asynchronous abort in checking window, the HYP data abort exception will be triggered and the abort source guest will be crashed. This is part of XSA-201. Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> commit f8c6a9334b251d2e78b0873a71b4d369908fb123 Author: Wei Chen <Wei.Chen@xxxxxxx> Date: Tue Nov 29 15:59:26 2016 +0100 arm: crash the guest when it traps on external abort If we spot a data or prefetch abort bearing the ESR_EL2.EA bit set, we know that this is an external abort, and that should crash the guest. This is part of XSA-201. Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reviewed-by: Steve Capper <steve.capper@xxxxxxx> Reviewed-by: Julien Grall <Julien.Grall@xxxxxxx> commit 36008800e81bc061cce1fd204a0b638f9dc61c70 Author: Wei Chen <Wei.Chen@xxxxxxx> Date: Tue Nov 29 15:58:57 2016 +0100 arm64: handle async aborts delivered while at EL2 If EL1 generates an asynchronous abort and then traps into EL2 (by HVC or IRQ) before the abort has been delivered, the hypervisor could not catch it, because the PSTATE.A bit is masked all the time in hypervisor. So this asynchronous abort may be slipped to next running guest with PSTATE.A bit unmasked. In order to avoid this, it is necessary to take the abort at EL2, by clearing the PSTATE.A bit. In this patch, we unmask the PSTATE.A bit to open a window to catch guest-generated asynchronous abort in all EL1 -> EL2 swich paths. If we catched such asynchronous abort in checking window, the hyp_error exception will be triggered and the abort source guest will be crashed. This is part of XSA-201. Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> commit 2cf7d2bafb9b68add1710b8c3f7ecad58e53a9db Author: Wei Chen <Wei.Chen@xxxxxxx> Date: Tue Nov 29 15:57:52 2016 +0100 arm64: handle guest-generated EL1 asynchronous abort In current code, when the hypervisor receives an asynchronous abort from a guest, the hypervisor will do panic, the host will be down. We have to prevent such security issue, so, in this patch we crash the guest, when the hypervisor receives an asynchronous abort from the guest. This is part of XSA-201. Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reviewed-by: Steve Capper <steve.capper@xxxxxxx> Reviewed-by: Julien Grall <Julien.Grall@xxxxxxx> (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |