|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.14-testing test] 154116: regressions - FAIL
flight 154116 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154116/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 152545 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass 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-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 483b43c4573329a28f1c9e18f90694e5be35ddb9 baseline version: xen c3a0fc22af90ef28e68b116c6a49d9cec57f71cf Last test of basis 152545 2020-08-09 11:18:37 Z 33 days Testing same since 154116 2020-09-11 12:36:19 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-qemuu-freebsd11-amd64 pass test-amd64-amd64-qemuu-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd 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 483b43c4573329a28f1c9e18f90694e5be35ddb9 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:11:43 2020 +0200 x86/pv: Rewrite segment context switching from scratch There are multiple bugs with the existing implementation. On AMD CPUs prior to Zen2, loading a NUL segment selector doesn't clear the segment base, which is a problem for 64bit code which typically expects to use a NUL %fs/%gs selector. On a context switch from any PV vcpu, to a 64bit PV vcpu with an %fs/%gs selector which faults, the fixup logic loads NUL, and the guest is entered at the failsafe callback with the stale base. Alternatively, a PV context switch sequence of 64 (NUL, non-zero base) => 32 (NUL) => 64 (NUL, zero base) will similarly cause Xen to enter the guest with a stale base. Both of these corner cases manifest as state corruption in the final vcpu. However, damage is limited to to 64bit code expecting to use Thread Local Storage with a base pointer of 0, which doesn't occur by default. The context switch logic is extremely complicated, and is attempting to optimise away loading a NUL selector (which is fast), or writing a 64bit base of 0 (which is rare). Furthermore, it fails to respect Linux's ABI with userspace, which manifests as userspace state corruption as far as Linux is concerned. Always restore all selector and base state, in all cases. Leave a large comment explaining hardware behaviour, and the new ABI expectations. Update the comments in the public headers. Drop all "segment preloading" to handle the AMD corner case. It was never anything but a waste of time for %ds/%es, and isn't needed now that %fs/%gs bases are unconditionally written for 64bit PV guests. In load_segments(), store the result of is_pv_32bit_vcpu() as it is an expensive predicate now, and not used in a way which impacts speculative safety. Reported-by: Andy Lutomirski <luto@xxxxxxxxxx> Reported-by: Sarah Newman <srn@xxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> x86/pv: Fix assertions in svm_load_segs() OSSTest has shown an assertion failure: http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log This is because we pass a non-NUL selector into svm_load_segs(), which is something we must not do, as this path does not load the attributes/limits from the GDT/LDT. Drop the {fs,gs}_sel parameters from svm_load_segs() and use 0 instead. This is acceptable even for non-zero NUL segments, as it is how the IRET instruction behaves in all CPUs. Only use the svm_load_segs() path when both FS and GS are NUL, which is the common case when scheduling a 64bit vcpu with 64bit userspace in context. Fixes: ad0fd291c5 ("x86/pv: Rewrite segment context switching from scratch") Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: ad0fd291c5e79191c2e3c70e43dded569f11a450 master date: 2020-09-07 11:32:34 +0100 master commit: 1e2d3be2e516e6f415ca6029f651b76a8563a27c master date: 2020-09-08 16:46:31 +0100 commit 431d52afd9438a3a126dfd787bd2d69b76906cb5 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:10:57 2020 +0200 x86/pv: Fix consistency of 64bit segment bases The comments in save_segments(), _toggle_guest_pt() and write_cr() are false. The %fs and %gs bases can be updated at any time by the guest. As a consequence, Xen's fs_base/etc tracking state is always stale when the vcpu is in context, and must not be used to complete MSR_{FS,GS}_BASE reads, etc. In particular, a sequence such as: wrmsr(MSR_FS_BASE, 0x1ull << 32); write_fs(__USER_DS); base = rdmsr(MSR_FS_BASE); will return the stale base, not the new base. This may cause guest a guest kernel's context switching of userspace to malfunction. Therefore: * Update save_segments(), _toggle_guest_pt() and read_msr() to always read the segment bases from hardware. * Update write_cr(), write_msr() and do_set_segment_base() to not not waste time caching data which is instantly going to become stale again. * Provide comments explaining when the tracking state is and isn't stale. This bug has been present for 14 years, but several bugfixes since have built on and extended the original flawed logic. Fixes: ba9adb737ba ("Apply stricter checking to RDMSR/WRMSR emulations.") Fixes: c42494acb2f ("x86: fix FS/GS base handling when using the fsgsbase feature") Fixed: eccc170053e ("x86/pv: Don't have %cr4.fsgsbase active behind a guest kernels back") Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: a5eaac9245f4f382a3cd0e9710e9d1cba7db20e4 master date: 2020-09-07 11:32:34 +0100 commit ceafff707c96ca5cf01a435e4cf6f64c2dfc9a4d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:10:26 2020 +0200 x86/pv: Fix multiple bugs with SEGBASE_GS_USER_SEL The logic takes the segment selector unmodified from guest context. This allowed the guest to load DPL0 descriptors into %gs. Fix up the RPL for non-NUL selectors to be 3. Xen's context switch logic skips saving the inactive %gs base, as it cannot be modified by the guest behind Xen's back. This depends on Xen caching updates to the inactive base, which is was missing from this path. The consequence is that, following SEGBASE_GS_USER_SEL, the next context switch will restore the stale inactive %gs base, and corrupt vcpu state. Rework the hypercall to update the cached idea of gs_base_user, and fix the behaviour in the case of the AMD NUL selector bug to always zero the segment base. Reported-by: Andy Lutomirski <luto@xxxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: afe018e041ec112d90a8b4e6ed607d22aa06f280 master date: 2020-08-31 14:21:46 +0100 commit 369e7a35bf651ce46778ff5598428b31c78924b7 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:09:56 2020 +0200 x86/intel: Expose MSR_ARCH_CAPS to dom0 The overhead of (the lack of) MDS_NO alone has been measured at 30% on some workloads. While we're not in a position yet to offer MSR_ARCH_CAPS generally to guests, dom0 doesn't migrate, so we can pass a subset of hardware values straight through. This will cause PVH dom0's not to use KPTI by default, and all dom0's not to use VERW flushing by default, and to use eIBRS in preference to retpoline on recent Intel CPUs. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: e46474278a0e87e2b32ad5dd5fc20e8d2cb0688b master date: 2020-08-31 13:43:26 +0100 commit 98aa6ea75152115297ad26aed6c1c5f8d202bdba Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:09:10 2020 +0200 x86: Begin to introduce support for MSR_ARCH_CAPS ... including serialisation/deserialisation logic and unit tests. There is no current way to configure this MSR correctly for guests. The toolstack side this logic needs building, which is far easier to do with it in place. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: e32605b07ef2e01c9d05da9b2d5d7b8f9a5c7c1b master date: 2020-08-27 12:48:46 +0100 commit 80dec06f6a5f4e56ef1f26087282402c21708ebf Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Fri Sep 11 14:08:37 2020 +0200 x86: use constant flags for section .init.rodata LLVM 11 complains with: <instantiation>:1:1: error: changed section flags for .init.rodata, expected: 0x2 .pushsection .init.rodata ^ <instantiation>:30:9: note: while in macro instantiation entrypoint 0 ^ entry.S:979:9: note: while in macro instantiation .rept 256 ^ And: entry.S:1015:9: error: changed section flags for .init.rodata, expected: 0x2 .section .init.rodata ^ Fix it by explicitly using the same flags and type in all the instances. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: d2770047a277ccdc7924fb99d1b051eeb0d5a90f master date: 2020-08-27 09:53:46 +0200 commit 5482c2887d89bf742fd982b8c47510617a5096ef Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Sep 11 14:08:09 2020 +0200 build: work around bash issue Older bash (observed with 3.2.57(2)) fails to honor "set -e" for certain built-in commands ("while" here), despite the command's status correctly being non-zero. The subsequent objcopy invocation now being separated by a semicolon results in no failure. Insert an explicit "exit" (replacing ; by && ought to be another possible workaround). Fixes: e321576f4047 ("xen/build: start using if_changed") Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 5132a0a37190b73c99dbbecf48dc4fb214feaf14 master date: 2020-08-07 13:12:00 +0200 commit edf5b8627fc8568d14bffef400a9753bf7ce5766 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:07:34 2020 +0200 x86/tsc: Fix diagnostics for TSC frequency A Gemini Lake platform prints: (XEN) CPU0: TSC: 19200000MHz * 279 / 3 = 1785600000MHz (XEN) CPU0: 800..1800 MHz during boot. The units on the first line are Hz, not MHz, so correct that and add a space for clarity. Also, for the min/max line, use three dots instead of two and add more spaces so that the line can't be mistaken for being a double decimal point typo. Boot now reads: (XEN) CPU0: TSC: 19200000 Hz * 279 / 3 = 1785600000 Hz (XEN) CPU0: 800 ... 1800 MHz Extend these changes to the other TSC diagnostics. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: b2bc1e714462c6cc222e3bbc38d87b039b4fa405 master date: 2020-08-05 17:35:11 +0100 commit eca6d5e914ddc134b3c4d2697e40002182eb6c06 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 11 14:06:48 2020 +0200 x86/ioapic: Fix fixmap error path logic in ioapic_init_mappings() In the case that bad_ioapic_register() fails, the current position of idx++ means that clear_fixmap(idx) will be called with the wrong index, and not clean up the mapping just created. Increment idx as part of the loop, rather than midway through the loop body. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: b4175c6693e089ffcd77cd1ea388e76e67d36d57 master date: 2020-08-05 17:35:11 +0100 (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |