|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.9-testing test] 114070: regressions - FAIL
flight 114070 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/114070/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113367 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113367 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113367 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 113367 test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 113367 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 113367 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail never pass 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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-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 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-check 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-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore 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-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-amd64-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 1cdcb36701fd22aec1106b5973d027f742e4f1dd baseline version: xen 2cc3d32f40c71cb242477a3f8938074d4fc36829 Last test of basis 113367 2017-09-12 13:11:34 Z 24 days Testing same since 114070 2017-10-06 13:15:32 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Chao Gao <chao.gao@xxxxxxxxx> Crawford, Eric R <Eric.R.Crawford@xxxxxxxxx> David Woodhouse <dwmw@xxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Stefano Stabellini <sstabellini@xxxxxxxxxx> Xiong Zhang <xiong.y.zhang@xxxxxxxxx> jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun 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-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-xl-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-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-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 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumprun-amd64 fail 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-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 pass test-amd64-amd64-xl-qemut-win10-i386 fail test-amd64-i386-xl-qemut-win10-i386 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-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-pygrub pass test-amd64-i386-libvirt-qcow2 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 fail 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 1cdcb36701fd22aec1106b5973d027f742e4f1dd Author: Julien Grall <julien.grall@xxxxxxx> Date: Fri Oct 6 14:59:38 2017 +0200 xen/arm: Correctly report the memory region in the dummy NUMA helpers NUMA is currently not supported on Arm. Because common code is NUMA-aware, dummy helpers are instead provided to expose a single node. Those helpers are for instance used to know the region to scrub. However the memory region is not reported correctly. Indeed, the frametable may not be at the beginning of the memory and there might be multiple memory banks. This will lead to not scrub some part of the memory. The memory information can be found using: * first_valid_mfn as the start of the memory * max_page - first_valid_mfn as the spanned pages Note that first_valid_mfn is now been exported. The prototype has been added in asm-arm/numa.h and not in a common header because I would expect the variable to become static once NUMA is fully supported on Arm. This is XSA-245. Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> master commit: 5414ba7f5e1ffc88ed2758b1e1b14bbfd3536a61 master date: 2017-09-29 13:23:11 -0700 commit 84c039eaf73a0ffd05a04330bb2763b0a2291609 Author: Julien Grall <julien.grall@xxxxxxx> Date: Fri Oct 6 14:59:00 2017 +0200 xen/page_alloc: Cover memory unreserved after boot in first_valid_mfn On Arm, some regions (e.g Initramfs, Dom0 Kernel...) are marked as reserved until the hardware domain is built and they are copied into its memory. Therefore, they will not be added in the boot allocator via init_boot_pages. Instead, init_xenheap_pages will be called once the region are not used anymore. Update first_valid_mfn in both init_heap_pages and init_boot_pages (already exist) to cover all the cases. This is XSA-245. Signed-off-by: Julien Grall <julien.grall@xxxxxxx> [Adjust comment, added locking around first_valid_mfn update] Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> master commit: ec6d9023e1f54cdccbf2e4c63cf947f1be2b1e8e master date: 2017-09-29 13:22:52 -0700 commit b244ac995c7c1ef79fc0e7cfbad146ec8f0445f3 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 6 14:57:55 2017 +0200 x86/HVM: correct repeat count update in linear->phys translation For the insn emulator's fallback logic in REP INS/OUTS handling to work correctly, *reps must not be set to zero when returning X86EMUL_UNHANDLEABLE. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Paul Durrant <paul.durrant@xxxxxxxxxx> master commit: 49160d205236d8e36d27d40b6bf69b9b75f2c333 master date: 2017-09-08 16:23:46 +0200 commit 612044a8097c303de522a034d0f03a07a7fed742 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 6 14:57:20 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman <security@xxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 0829a6bdbdc6b79990bd0668e847275b6a2717e5 master date: 2017-09-06 12:32:00 +0200 commit e8fd37235064347cfd8c089b48e23280551d35a3 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 6 14:56:47 2017 +0200 x86emul: correct VEX.L handling for VCVT{,T}S{S,D}2SI Recent changes to the SDM (and XED) have made clear that older hardware raising #UD when the bit is set was really an erratum. Generalize the so far AMD-only override. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: a6488965ca3ec30f2e0b7022b539bba78c2aeede master date: 2017-09-05 17:32:05 +0200 commit a568e25a38e55d15ca8b003e281ce9bc28fcee24 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 6 14:56:11 2017 +0200 x86emul: correct VEX.W handling for non-64-bit VPINSRD Going though the XED commits from the last couple of months made me notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non- 64-bit modes, leading to an insertion of stray 32-bits of zero in case the original instruction had the bit set. Also remove a pointless fall-through in VPEXTRW handling, bringing things in line with VPINSRW. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 9c2babd05a213f8802e3cc1c64a2af932b5cbd7d master date: 2017-09-05 17:31:01 +0200 commit 8fef83e60bc3036c8bf4d37d59114c766610be7c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Oct 6 14:55:33 2017 +0200 x86/emul: Fix the handling of unimplemented Grp7 instructions Grp7 is abnormally complicated to decode, even by x86's standards, with {s,l}msw being the problematic cases. Previously, any value which fell through the first switch statement (looking for instructions with entirely implicit operands) would be interpreted by the second switch statement (handling instructions with memory operands). Unimplemented instructions would then hit the #UD case for having a non-memory operand, rather than taking the cannot_emulate path. Consolidate the two switch statements into a single one, using ranges to cover the instructions with memory operands. Reported-by: Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <JBeulich@xxxxxxxx> master commit: 4d3f0fde471e7588ce512eaff1abdab209d8cd4b master date: 2017-09-05 12:58:47 +0100 commit 478e40cd6447b343a47ce99b8401f7dece770799 Author: Chao Gao <chao.gao@xxxxxxxxx> Date: Fri Oct 6 14:54:51 2017 +0200 VT-d: use correct BDF for VF to search VT-d unit When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under the scope of the same VT-d unit as the 'Physical Function'. A 'Physical Function' can be a 'Traditional Function' or an ARI 'Extended Function'. And furthermore, 'Extended Functions' on an endpoint are under the scope of the same VT-d unit as the 'Traditional Functions' on the endpoint. To search VT-d unit for a VF, if its PF isn't an extended function, the BDF of PF should be used. Otherwise the BDF of a traditional function in the same device with the PF should be used. Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'. But it is conceptually wrong w/o checking whether PF is an extended function and would lead to match VFs of a RC integrated PF to a wrong VT-d unit. This patch overrides VF 'is_extfn' field and uses this field to indicate whether the PF of this VF is an extended function. The field helps to use correct BDF to search VT-d unit. Reported-by: Crawford, Eric R <Eric.R.Crawford@xxxxxxxxx> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Crawford, Eric R <Eric.R.Crawford@xxxxxxxxx> master commit: c286af54c7177c14180121b422d8df7281e547cb master date: 2017-09-01 11:02:23 +0200 commit 22ea7316e5440b16965471b5c1026f178ee9683e Author: Xiong Zhang <xiong.y.zhang@xxxxxxxxx> Date: Fri Oct 6 14:54:24 2017 +0200 hvmloader: use base instead of pci_mem_start for find_next_rmrr() find_next_rmrr(base) is used to find the lowest RMRR ending above base but below 4G. Current method couldn't cover the following situation: a. two rmrr exist, small gap between them b. pci_mem_start and mem_resource.base is below the first rmrr.base c. find_next_rmrr(pci_mem_start) will find the first rmrr d. After aligning mem_resource.base to bar size, first_rmrr.end < new_base < second_rmrr.base and new_base + bar_sz > second_rmrr.base. So the new bar will overlap with the second rmrr and doesn't overlap with the first rmrr. But the next_rmrr point to the first rmrr, then check_overlap() couldn't find the overlap. Finally assign a wrong address to bar. This patch using aligned new base to find the next rmrr, could fix the above case and find all the overlapped rmrr with new base. Signed-off-by: Xiong Zhang <xiong.y.zhang@xxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: ecc607b1851bc27140090da4d6124fd00090ec2b master date: 2017-08-28 10:51:24 +0200 commit e7703a2e86f9002b414b6b6138c2f649af3224bc Author: David Woodhouse <dwmw@xxxxxxxxxxxx> Date: Fri Oct 6 14:53:51 2017 +0200 x86/efi: don't write relocations in efi_arch_relocate_image() first pass The function is invoked with delta=0 before ExitBootServices() is called, as a dummy run purely to validate that all the relocations can be handled. This allows us to exit gracefully with an error message. However, we have relocations in read-only sections such as .rodata and .init.te(xt). Recent versions of UEFI will actually make those sections read-only, which will cause a fault. This functionaity was added in EDK2 commit d0e92aad4 ("MdeModulePkg/DxeCore: Add UEFI image protection.") It's OK to actually make the changes in the later pass because UEFI will tear down the protection when ExitBootServices() is called, because it knows we're going to need to do this kind of thing. Reported-by: Jan Beulich <jbeulich@xxxxxxxx> Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx> master commit: 34828425d36b560adfe96430b9b83dfb0f66f2a8 master date: 2017-08-25 14:07:40 +0200 commit 91ded3b748a6cbfa6a53a8e02df985c3f9d90ad6 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 6 14:52:48 2017 +0200 x86: check for allocation errors in modify_xen_mappings() Reported-by: Julien Grall <julien.grall@xxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: e466ec4f51d38a2c9d02bf9f3d5e43e47db2d66b master date: 2017-08-25 14:03:47 +0200 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |