|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 18184: regressions - FAIL
flight 18184 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18184/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. vs. 18182 build-i386-pvops 4 kernel-build fail REGR. vs. 18182 build-i386 4 xen-build fail REGR. vs. 18182 build-i386-oldkern 4 xen-build fail REGR. vs. 18182 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 18182 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a version targeted for testing: xen 6809b4859f186d74a0eed31fba1d90c7f32e1a69 baseline version: xen a12d15d8c1d512a4ed6498b39f9058f69a1c1f6c ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> (re 4.3 release) Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Keir Fraser <keir@xxxxxxx> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 fail build-amd64-oldkern pass build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops fail test-amd64-amd64-xl pass test-amd64-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-xl-qemut-winxpsp3-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-i386-xend-qemut-winxpsp3 blocked test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6809b4859f186d74a0eed31fba1d90c7f32e1a69 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Jun 21 17:36:26 2013 +0100 tools/libxc: Fix memory leaks in xc_domain_restore() Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> (re 4.3 release) Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> commit c74c1f906a04e110dea7c0b4156ec74b43a3951c Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Tue Jun 18 10:08:01 2013 +0100 libxl,hvmloader: Don't relocate memory for MMIO hole At the moment, qemu-xen can't handle memory being relocated by hvmloader. This may happen if a device with a large enough memory region is passed through to the guest. At the moment, if this happens, then at some point in the future qemu will crash and the domain will hang. (qemu-traditional is fine.) It's too late in the release to do a proper fix, so we try to do damage control. hvmloader already has mechanisms to relocate memory to 64-bit space if it can't make a big enough MMIO hole. By default this is 2GiB; if we just refuse to make the hole bigger if it will overlap with guest memory, then the relocation will happen by default. v5: - Update comment to not refer to "this series". v4: - Wrap long line in libxl_dm.c - Fix comment v3: - Fix polarity of comparison - Move diagnostic messages to another patch - Tested with xen platform pci device hacked to have different BAR sizes {256MiB, 1GiB} x {qemu-xen, qemu-traditional} x various memory configurations - Add comment explaining why we default to "allow" - Remove cast to bool v2: - style fixes - fix and expand comment on the MMIO hole loop - use "%d" rather than "%s" -> (...)?"1":"0" - use bool instead of uint8_t - Move 64-bit bar relocate detection to another patch - Add more diagnostic messages Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit 6392092e7e04b2c40145743ba1a078499210af9a Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Tue Jun 18 14:56:29 2013 +0100 hvmloader: Remove minimum size for BARs to relocate to 64-bit space Allow devices with BARs less than 512MiB to be relocated to high memory. This will only be invoked if there is not enough low MMIO space to map the device, and will be done preferentially to large devices first; so in all likelihood only large devices will be remapped anyway. This is needed to work-around the issue of qemu-xen not being able to handle moving guest memory around to resize the MMIO hole. The default MMIO hole size is less than 256MiB. v3: - Fixed minor style issue Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit 56fb55c42ec4cca9d7bd702d85b15a25c62da691 Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Tue Jun 18 15:32:35 2013 +0100 hvmloader: Load large devices into high MMIO space as needed Keep track of how much mmio space is left total, as well as the amount of "low" MMIO space (<4GiB), and only load devices into high memory if there is not enough low memory for the rest of the devices to fit. Because devices are processed by size in order from large to small, this should preferentially relocate devices with large BARs to 64-bit space. v3: - Just use mmio_total rather than introducing a new variable. - Port to using mem_resource directly rather than low_mmio_left Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit 703e150231e26079d72ecca76701a825e7b9b927 Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Tue Jun 18 15:11:03 2013 +0100 hvmloader: Correct bug in low mmio region accounting When deciding whether to map a device in low MMIO space (<4GiB), hvmloader compares it with "mmio_left", which is set to the size of the low MMIO range (pci_mem_end - pci_mem_start). However, even if it does map a device in high MMIO space, it still removes the size of its BAR from mmio_left. In reality we don't need to do a separate accounting of the low memory available -- this can be calculated from mem_resource. Just get rid of the variable and the duplicate accounting entirely. This will make the code more robust. Note also that the calculation of whether to move a device to 64-bit is fragile at the moment, depending on some unstated assumptions. State those assumptions in a comment for future reference. v5: - Add comment documenting fragility of the move-to-highmem check v3: - Use mem_resource values directly instead of doing duplicate accounting Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit 3458ab670f3043100f2c0ae5634c44226eb3d2ca Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Tue Jun 18 12:48:36 2013 +0100 hvmloader: Fix check for needing a 64-bit bar After attempting to resize the MMIO hole, the check to determine whether there is a need to relocate BARs into 64-bit space checks the specific thing that caused the loop to exit (MMIO hole == 2GiB) rather than checking whether the required MMIO will fit in the hole. But even then it does it wrong: the polarity of the check is backwards. Check for the actual condition we care about (the sizeof the MMIO hole) rather than checking for the loop exit condition. v3: - Move earlier in the series, before other functional changes Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> CC: Ian Jackson <ian.jackson@xxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit 42d075411bc68effe8c75dca27447ba7c72da208 Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Wed Jun 19 17:30:13 2013 +0100 hvmloader: Set up highmem resouce appropriately if there is no RAM above 4G hvmloader will read hvm_info->high_mem_pgend to calculate where to start the highmem PCI region. However, if the guest does not have any memory in the high region, this is set to zero, which will cause hvmloader to use the "0" for the base of the highmem region, rather than 1 << 32. Check to see whether hvm_info->high_mem_pgend is set; if so, do the normal calculation; otherwise, use 1<<32. v4: - Handle case where hfm_info->high_mem_pgend is non-zero but doesn't point into high memory, throwing a warning. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Ian Jackson <ian.jackson@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit 91993aee68cd6b43f72e1ada33b295388fa5c4c1 Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Wed Jun 19 14:47:46 2013 +0100 hvmloader: Make the printfs more informative * Warn that you're relocating some BARs to 64-bit * Warn that you're relocating guest pages, and how many * Include upper 32-bits of the base register when printing the bar placement info v4: - Move message about relocating guest pages into loop, include number of pages and guest paddr - Fixed minor brace style issue Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Ian Jackson <ian.jackson@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> commit d23749aaf76330730e0d0d86f2ccfc1effd54e3a Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Wed Jun 19 13:52:20 2013 +0100 hvmloader: Remove all 64-bit print arguments The printf() available to hvmloader does not handle 64-bit data types; manually break them down as two 32-bit strings. v4: - Make macros for the requisite format and bit shifting Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Ian Jackson <ian.jackson@xxxxxxxxxx> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> CC: Hanweidong <hanweidong@xxxxxxxxxx> CC: Keir Fraser <keir@xxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |