|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.11-testing test] 132588: regressions - FAIL
flight 132588 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/132588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860 test-xtf-amd64-amd64-3 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860 test-xtf-amd64-amd64-2 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 130860 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 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-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop 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-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop 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-xl-qemut-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-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-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-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-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen df1debf494ac38c95abb602b2b3057613de06b47 baseline version: xen 96cbd0893f783997caaf117e897d5fa8f2dc7b5f Last test of basis 130860 2018-11-29 14:06:50 Z 62 days Failing since 132486 2019-01-26 01:36:53 Z 5 days 2 attempts Testing same since 132588 2019-01-29 20:27:18 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Julien Grall <julien.grall@xxxxxxx> Marc Zyngier <marc.zyngier@xxxxxxx> Shameer Kolothum <shameerali.kolothum.thodi@xxxxxxxxxx> Stefano Stabellini <sstabellini@xxxxxxxxxx> Stefano Stabellini <stefanos@xxxxxxxxxx> jobs: build-amd64-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-amd64-i386-libvirt-xsm pass test-amd64-amd64-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-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 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-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 fail 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-amd64-xl-pvhv2-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-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-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-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 df1debf494ac38c95abb602b2b3057613de06b47 Author: Julien Grall <julien.grall@xxxxxxx> Date: Fri Oct 19 15:23:55 2018 +0100 xen/arm: Don't build GICv3 with the new vGIC Commit 54ec59f6b0 "xen/arm: vgic-v3: Don't create empty re-distributor regions" breaks compilation when using the new vGIC. This is because the field nr_regions is not existing in the vgic structure. For simplicity, as vGICv3 is not yet imported, disable GICv3. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit 62aa9e7f1b8ef64b8c7c1dacb1122351cb9fd132) commit 14b7dc115b8a5d90cf842ac003100542408f671c Author: Julien Grall <julien.grall@xxxxxxx> Date: Mon Oct 1 17:42:27 2018 +0100 xen/arm: vgic-v3: Don't create empty re-distributor regions At the moment, Xen is assuming the hardware domain will have the same number of re-distributor regions as the host. However, as the number of CPUs or the stride (e.g on GICv4) may be different we end up exposing regions which does not contain any re-distributors. When booting, Linux will go through all the re-distributor region to check whether a property (e.g vPLIs) is available accross all the re-distributors. This will result to a data abort on empty regions because there are no underlying re-distributor. So we need to limit the number of regions exposed to the hardware domain. The code reworked to only expose the minimun number of regions required by the hardware domain. It is assumed the regions will be populated starting from the first one. Lastly, rename vgic_v3_rdist_count to reflect the value return by the helper. Reported-by: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@xxxxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit 54ec59f6b0b363c34cf1864d5214a05e35ea75ee) commit 015b00ff3581d5f83cbc0ea96ebdc3900f12053e Author: Julien Grall <julien.grall@xxxxxxx> Date: Mon Oct 1 17:42:26 2018 +0100 xen/arm: vgic-v3: Delay the initialization of the domain information A follow-up patch will require to know the number of vCPUs when initializating the vGICv3 domain structure. However this information is not available at domain creation. This is only known once XEN_DOMCTL_max_vpus is called for that domain. In order to get the max vCPUs around, delay the domain part of the vGIC v3 initialization until the first vCPU of the domain is initialized. Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@xxxxxxxxxx> Acked-but-disliked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db) commit 02fd1ee8ce00ca2a1b89bb17703d667209fc49fb Author: Stefano Stabellini <sstabellini@xxxxxxxxxx> Date: Tue Nov 13 08:45:49 2018 -0800 xen/arm: check for multiboot nodes only under /chosen Make sure to only look for multiboot compatible nodes only under /chosen, not under any other paths (depth <= 3). Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx> [julien: Use sizeof(path) instead of len ] Reviewed-by: Julien Grall <julien.grall@xxxxxxx> (cherry picked from commit c32e3689c546305d4eae53e6ccf9c8b4e048c7df) commit dd1c98afc670209067479a32f10041a6ace48fad Author: Julien Grall <julien.grall@xxxxxxx> Date: Tue Oct 23 19:17:07 2018 +0100 xen/arm: gic: Ensure ordering between read of INTACK and shared data When an IPI is generated by a CPU, the pattern looks roughly like: <write shared data> dsb(sy); <write to GIC to signal SGI> On the receiving CPU we rely on the fact that, once we've taken the interrupt, then the freshly written shared data must be visible to us. Put another way, the CPU isn't going to speculate taking an interrupt. Unfortunately, this assumption turns out to be broken. Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy to read some shared_data. Before CPUx has done anything, a random peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised. CPUy then takes the IRQ and starts executing the entry code, heading towards gic_handle_irq. Furthermore, let's assume that a bunch of the previous interrupts handled by CPUy were SGIs, so the branch predictor kicks in and speculates that irqnr will be <16 and we're likely to head into handle_IPI. The prefetcher then grabs a speculative copy of shared_data which contains a stale value. Meanwhile, CPUx gets round to updating shared_data and asking the GIC to send an SGI to CPUy. Internally, the GIC decides that the SGI is more important than the peripheral interrupt (which hasn't yet been ACKed) but doesn't need to do anything to CPUy, because the IRQ line is already raised. CPUy then reads the ACK register on the GIC, sees the SGI value which confirms the branch prediction and we end up with a stale shared_data value. This patch fixes the problem by adding an smp_rmb() to the IPI entry code in do_SGI. At the same time document the write barrier. Based on Linux commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 "irqchip/gic: Ensure ordering between read of INTACK and shared data". Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Andrii Anisov<andrii_anisov@xxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit 555e5f1bd26c4c1995357e9671b3e42a68d5ce8f) commit 28f380fbdec3d31d64afebfca2d7a58a4642b405 Author: Julien Grall <julien.grall@xxxxxxx> Date: Tue Oct 23 19:17:06 2018 +0100 xen/arm: gic: Ensure we have an ISB between ack and do_IRQ() Devices that expose their interrupt status registers via system registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer, vgic (although unused by Linux), ...) rely on a context synchronising operation on the CPU to ensure that the updated status register is visible to the CPU when handling the interrupt. This usually happens as a result of taking the IRQ exception in the first place, but there are two race scenarios where this isn't the case. For example, let's say we have two peripherals (X and Y), where Y uses a system register for its interrupt status. Case 1: 1. CPU takes an IRQ exception as a result of X raising an interrupt 2. Y then raises its interrupt line, but the update to its system register is not yet visible to the CPU 3. The GIC decides to expose Y's interrupt number first in the Ack register 4. The CPU runs the IRQ handler for Y, but the status register is stale Case 2: 1. CPU takes an IRQ exception as a result of X raising an interrupt 2. CPU reads the interrupt number for X from the Ack register and runs its IRQ handler 3. Y raises its interrupt line and the Ack register is updated, but again, the update to its system register is not yet visible to the CPU. 4. Since the GIC drivers poll the Ack register, we read Y's interrupt number and run its handler without a context synchronisation operation, therefore seeing the stale register value. In either case, we run the risk of missing an IRQ. This patch solves the problem by ensuring that we execute an ISB in the GIC drivers prior to invoking the interrupt handler. Based on Linux commit 39a06b67c2c1256bcf2361a1f67d2529f70ab206 "irqchip/gic: Ensure we have an ISB between ack and ->handle_irq". Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Andrii Anisov<andrii_anisov@xxxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit 177afec4556c676e5a1a958d1626226fbca2a696) commit 0be54438731fa6345f14f079a82f6eb1c8b8db45 Author: Marc Zyngier <marc.zyngier@xxxxxxx> Date: Tue Sep 25 18:20:39 2018 +0100 xen/arm: smccc-1.1: Handle function result as parameters If someone has the silly idea to write something along those lines: extern u64 foo(void); void bar(struct arm_smccc_res *res) { arm_smccc_1_1_smc(0xbad, foo(), res); } they are in for a surprise, as this gets compiled as: 0000000000000588 <bar>: 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 <foo> 5a4: aa0003e1 mov x1, x0 5a8: d4000003 smc #0x0 5ac: b4000073 cbz x19, 5b8 <bar+0x30> 5b0: a9000660 stp x0, x1, [x19] 5b4: a9010e62 stp x2, x3, [x19, #16] 5b8: f9400bf3 ldr x19, [sp, #16] 5bc: a8c27bfd ldp x29, x30, [sp], #32 5c0: d65f03c0 ret 5c4: d503201f nop The call to foo "overwrites" the x0 register for the return value, and we end up calling the wrong secure service. A solution is to evaluate all the parameters before assigning anything to specific registers, leading to the expected result: 0000000000000588 <bar>: 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 <foo> 5a4: aa0003e1 mov x1, x0 5a8: d28175a0 mov x0, #0xbad 5ac: d4000003 smc #0x0 5b0: b4000073 cbz x19, 5bc <bar+0x34> 5b4: a9000660 stp x0, x1, [x19] 5b8: a9010e62 stp x2, x3, [x19, #16] 5bc: f9400bf3 ldr x19, [sp, #16] 5c0: a8c27bfd ldp x29, x30, [sp], #32 5c4: d65f03c0 ret Reported-by: Stefano Stabellini <stefanos@xxxxxxxxxx> Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit fa7974f743b2d95af1d0983f86e8be0ed9a9e4be) commit ad8875c8a7b55f4e7b5641ca4a7312b78bcf4c91 Author: Marc Zyngier <marc.zyngier@xxxxxxx> Date: Tue Sep 25 18:20:38 2018 +0100 xen/arm: smccc-1.1: Make return values unsigned long An unfortunate consequence of having a strong typing for the input values to the SMC call is that it also affects the type of the return values, limiting r0 to 32 bits and r{1,2,3} to whatever was passed as an input. Let's turn everything into "unsigned long", which satisfies the requirements of both architectures, and allows for the full range of return values. Reported-by: Stefano Stabellini <stefanos@xxxxxxxxxx> Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (cherry picked from commit 35fc6086124ffe27d297801616e7ac6dc344040b) (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 |