|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 93999: regressions - FAIL
flight 93999 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/93999/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 93921 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-check fail never pass version targeted for testing: xen c1b368ee2e00741a118fe4f972fbb5347db067ba baseline version: xen 2656bc7b0c145932e1af80d54d48975edd081997 Last test of basis 93921 2016-05-09 17:01:17 Z 1 days Testing same since 93999 2016-05-10 18:01:01 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> Tim Deegan <tim@xxxxxxx> jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail 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 c1b368ee2e00741a118fe4f972fbb5347db067ba Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 10 18:56:53 2016 +0100 QEMU_TAG update commit fec659aa2dd9cfc9f35f05266179bbdde75203f0 Author: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> Date: Tue May 10 10:10:02 2016 +0100 xsplice: Prevent new symbols duplicating core symbols When loading patches, the code prevents loading a patch containing a new symbol that duplicates a symbol from another loaded patch. However, the check should also prevent loading a new symbol that duplicates a symbol from the core hypervisor. Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 31d961f38bcb0a8fe899bc46a3ef7d05fb381c2b Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon May 9 13:13:57 2016 +0000 x86/hvm: Fix invalidation for emulated invlpg instructions hap_invlpg() is reachable from the instruction emulator, which means introspection and tests using hvm_fep can end up here. As such, crashing the domain is not an appropriate action to take. Fixing this involves rearranging the callgraph. paging_invlpg() is now the central entry point. It first checks for the non-canonical NOP case, and calls ino the paging subsystem. If a real flush is needed, it will call the appropriate handler for the vcpu. This allows the PV callsites of paging_invlpg() to be simplified. The sole user of hvm_funcs.invlpg_intercept() is altered to use paging_invlpg() instead, allowing the .invlpg_intercept() hook to be removed. For both VMX and SVM, the existing $VENDOR_invlpg_intercept() is split in half. $VENDOR_invlpg_intercept() stays as the intercept handler only (which just calls paging_invlpg()), and new $VENDOR_invlpg() functions do the ASID/VPID management. These later functions are made available in hvm_funcs for paging_invlpg() to use. As a result, correct ASID/VPID management occurs for the hvmemul path, even if it did not originate from an real hardware intercept. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit eee511dec9d1f7e2bdfb4aebfe5ffbd70cdf6f51 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon May 9 18:09:38 2016 +0100 x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept() paging_invlpg() already returns a boolean indicating whether an invalidation is necessary or not. A return value of 0 indicates that the specified virtual address wasn't shadowed (or has already been flushed), cannot currently be cached in the TLB. This is a performance optimisation. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit a373db28eaa1e9011db00cc6359b8ee1112c80e0 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Apr 22 09:44:53 2016 +0100 x86/hvm: Correct the emulated interaction of invlpg with segments The `invlpg` instruction is documented to take a memory address, and is not documented to suffer faults from segmentation violations. It is also explicitly documented to be a NOP when issued on a non-canonical address. Experimentally, and subsequently confirmed by both Intel and AMD, the instruction does take into account segment bases, but will happily invalidate a TLB entry for a mapping beyond the segment limit. The emulation logic will currently raise #GP/#SS faults for segment limit violations, or non-canonical addresses, which doesn't match hardware's behaviour. Instead, squash exceptions generated by hvmemul_virtual_to_linear() and proceed with invalidation. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit a94b35ddedf5c7327c6b2d9205d0a2aef2e4cfed Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Sat May 7 13:41:05 2016 +0100 x86/hvm: Raise #SS faults for %ss-based segmentation violations Raising #GP under such circumstances is architecturally wrong. Refer to the Intel or AMD manuals describing faults, and the conditions under which #SS is raised. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 60935158cbf74f4cd6f69190ced9be0391cfa506 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed May 4 14:52:24 2016 +0100 x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr() Some callers need the linear address (with appropriate segment base), whether or not the limit or canonical check succeeds. While modifying the function, change the return type to bool_t to match its semantics. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit fdb9a18698c9ab8e8e8e875f20184b4aa5d62825 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue May 10 14:37:00 2016 +0100 sched/rt: Fix memory leak in rt_init() c/s 2656bc7b0 "xen: adopt .deinit_pdata and improve timer handling" introduced a error path into rt_init() which leaked prv if the allocation of prv->repl_timer failed. Introduce an error cleanup path. Spotted by Coverity. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Meng Xu <mengxu@xxxxxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> --- CC: George Dunlap <george.dunlap@xxxxxxxxxxxxx> CC: Dario Faggioli <dario.faggioli@xxxxxxxxxx> (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |