|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 133469: regressions - FAIL
flight 133469 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133469/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-build fail REGR. vs. 133457 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 1c8ca185e3c6e003398471edd9dbac0cd118137c baseline version: xen 346e7d0f4b2179b9e0b09f4ebc98cbb3aae39a2c Last test of basis 133457 2019-02-27 14:00:42 Z 1 days Testing same since 133469 2019-02-28 12:00:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Christian Lindig <christian.lindig@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 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 Not pushing. ------------------------------------------------------------ commit 1c8ca185e3c6e003398471edd9dbac0cd118137c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Feb 28 10:48:16 2019 +0000 x86/hvm: Increase the triple fault log message level to XENLOG_ERR At INFO level, it doesn't get printed out by default in release builds, leading to unqualified logging such as this: (XEN) [ 66.995993] Freed 524kB init memory (XEN) [ 1993.144997] *** Dumping Dom9 vcpu#2 state: *** (XEN) [ 1993.145008] ----[ Xen-4.11.1 x86_64 debug=n Not tainted ]---- (XEN) [ 1993.145011] CPU: 21 (XEN) [ 1993.145015] RIP: 0010:[<ffffe0002ba950ef>] (XEN) [ 1993.145018] RFLAGS: 0000000000010246 CONTEXT: hvm guest (d9v2) (XEN) [ 1993.145026] rax: 00000000ffffe000 rbx: ffffe0002d8e1440 rcx: 0000ffffe0002ba9 (XEN) [ 1993.145031] rdx: 0000000000000000 rsi: ffffe0002ba93575 rdi: fffff803dfb9f340 (XEN) [ 1993.145035] rbp: ffffd001cd791200 rsp: ffffd001cd791140 r8: 0000000000000130 (XEN) [ 1993.145039] r9: 0000000080000000 r10: 0000000000000000 r11: 0000000000000020 (XEN) [ 1993.145043] r12: ffffe0002ba9306d r13: 0000000000000000 r14: 0000000000000001 (XEN) [ 1993.145047] r15: fffff803dfb9f200 cr0: 0000000080050031 cr4: 0000000000170678 (XEN) [ 1993.145051] cr3: 00000000001aa002 cr2: 0000020488403f70 (XEN) [ 1993.145056] fsb: 0000000060f71000 gsb: ffffd001cc1af000 gss: 0000009d60f6f000 (XEN) [ 1993.145060] ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018 cs: 0010 A triple fault is fatal to the domain under all circumstances (so will print at most once), and in practice is always an error condition rather than a reboot fallback. Reported-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Juergen Gross <jgross@xxxxxxxx> commit 677e64dbe315343620c3b266e9eb16623b118038 Author: Christian Lindig <christian.lindig@xxxxxxxxxx> Date: Wed Feb 27 10:33:42 2019 +0000 tools/ocaml: Dup2 /dev/null to stdin in daemonize() Don't close stdin in daemonize() but dup2 /dev/null instead. Otherwise, fd 0 gets reused later: [root@idol ~]# ls -lav /proc/`pgrep xenstored`/fd total 0 dr-x------ 2 root root 0 Feb 28 11:02 . dr-xr-xr-x 9 root root 0 Feb 27 15:59 .. lrwx------ 1 root root 64 Feb 28 11:02 0 -> /dev/xen/evtchn l-wx------ 1 root root 64 Feb 28 11:02 1 -> /dev/null l-wx------ 1 root root 64 Feb 28 11:02 2 -> /dev/null lrwx------ 1 root root 64 Feb 28 11:02 3 -> /dev/xen/privcmd ... Signed-off-by: Christian Lindig <christian.lindig@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Juergen Gross <jgross@xxxxxxxx> commit 69f7643df68ef8e994221a996e336a47cbb7bbc8 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Feb 11 13:31:02 2019 +0000 x86/vmx: Properly flush the TLB when an altp2m is modified Modifications to an altp2m mark the p2m as needing flushing, but this was never wired up in the return-to-guest path. As a result, stale TLB entries can remain after resuming the guest. In practice, this manifests as a missing EPT_VIOLATION or #VE exception when the guest subsequently accesses a page which has had its permissions reduced. vmx_vmenter_helper() now has 11 p2ms to potentially invalidate, but issuing 11 INVEPT instructions isn't clever. Instead, count how many contexts need invalidating, and use INVEPT_ALL_CONTEXT if two or more are in need of flushing. This doesn't have an XSA because altp2m is not yet a security-supported feature. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-acked-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> commit 0ec9b4ef3148e052bd8adf83800d7d681571f49e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Jan 17 12:26:17 2019 +0000 x86/vmx: Fix security issue when a guest balloons out the #VE info page The logic in altp2m_vcpu_{en,dis}able_ve() and vmx_vcpu_update_vmfunc_ve() is dangerous. After #VE has been set up, the guest can balloon out and free the nominated GFN, after which the processor may write to it. Also, the unlocked GFN query means the MFN is stale by the time it is used. Alternatively, a guest can race two disable calls to cause one VMCS to still reference the nominated GFN after the tracking information was dropped. Rework the logic from scratch to make it safe. Hold an extra page reference on the underlying frame, to account for the VMCS's reference. This means that if the GFN gets ballooned out, it isn't freed back to Xen until #VE is disabled, and the VMCS no longer refers to the page. A consequence of this is that altp2m_vcpu_disable_ve() needs to be called during the domain_kill() path, to drop the reference for domains which shut down with #VE still enabled. For domains using altp2m, we expect a single enable call and no disable for the remaining lifetime of the domain. However, to avoid problems with concurrent calls, use cmpxchg() to locklessly maintain safety. This doesn't have an XSA because altp2m is not yet a security-supported feature. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Release-acked-by: Juergen Gross <jgross@xxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |