|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.13-testing test] 146171: regressions - FAIL
flight 146171 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/146171/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR. vs. 145145 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 145145 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail blocked in 145145 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-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-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 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-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-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-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-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-i386-xl-qemut-win7-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-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-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-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-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 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-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop 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 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 721f2c323ca55c77857c93e7275b4a93a0e15e1f baseline version: xen 6a10d046b0ab9231714ffccea7a59036f52df1a7 Last test of basis 145145 2019-12-23 11:06:31 Z 24 days Failing since 146079 2020-01-14 14:36:30 Z 2 days 3 attempts Testing same since 146171 2020-01-16 17:29:05 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Julien Grall <jgrall@xxxxxxxxxx> Julien Grall <julien@xxxxxxx> Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Paul Durrant <pdurrant@xxxxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Tao Xu <tao3.xu@xxxxxxxxx> 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-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-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-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-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 fail 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 fail test-armhf-armhf-xl-rtds fail 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 721f2c323ca55c77857c93e7275b4a93a0e15e1f Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Jan 15 14:24:47 2020 +0100 x86: clear per cpu stub page information in cpu_smpboot_free() cpu_smpboot_free() removes the stubs for the cpu going offline, but it isn't clearing the related percpu variables. This will result in crashes when a stub page is released due to all related cpus gone offline and one of those cpus going online later. Fix that by clearing stubs.addr and stubs.mfn in order to allocate a new stub page when needed, irrespective of whether the CPU gets parked or removed. Fixes: 2e6c8f182c9c50 ("x86: distinguish CPU offlining from CPU removal") Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: Wei Liu <wl@xxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Tao Xu <tao3.xu@xxxxxxxxx> master commit: 774901788c5614798931a1cb2e20dd8b885f97ab master date: 2020-01-09 11:07:38 +0100 commit 3baeeedc9f796f6ef5595c2999a4135f28e1a4ab Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Jan 15 14:24:09 2020 +0100 sched: fix resuming from S3 with smt=0 When resuming from S3 and smt=0 or maxcpus= are specified we must not do anything in cpu_schedule_callback(). This is not true today for taking down a cpu during resume. If anything goes wrong during resume all the scheduler related error handling is in cpupool.c, so we can just bail out early from cpu_schedule_callback() when suspending or resuming. This fixes commit 0763cd2687897b55e7 ("xen/sched: don't disable scheduler on cpus during suspend"). Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Tested-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: d7f3c76317108ee9989f00545d394fa495fba752 master date: 2020-01-08 14:59:25 +0100 commit 01acc256eb71f3bedf5212b696eece325eb2eacf Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Wed Jan 15 14:23:36 2020 +0100 x86/tlbflush: do not toggle the PGE CR4 bit unless necessary When PCID is not available Xen does a full tlbflush by toggling the PGE bit in CR4. This is not necessary if PGE is not enabled, since a flush can be performed by writing to CR3 in that case. Change the code in do_tlb_flush to only toggle the PGE bit in CR4 if it's already enabled, otherwise do the tlb flush by writing to CR3. This is relevant when running virtualized, since hypervisors don't usually trap accesses to CR3 when using hardware assisted paging, but do trap accesses to CR4 specially on AMD hardware, which makes such accesses much more expensive. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: b5087a31efee7a4e34c958b88671ac6669501b09 master date: 2019-12-03 14:15:35 +0100 commit fe0496eab866c32e344068ba926d2cc63ae6b04f Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Jan 15 14:22:57 2020 +0100 x86: avoid HPET use on certain Intel platforms Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered PC10, which in consequence marks TSC as unstable because HPET is used as watchdog clocksource for TSC." Follow this for Xen as well. Looking at its patch context made me notice they have a pre-existing quirk for Bay Trail as well. The comment there, however, points at a Cherry Trail document. Looking at the datasheets of both, there appear to be similar issues, so go beyond Linux'es coverage and exclude both. Also key the disable on the PCI IDs of the actual affected devices, rather than those of 00:00.0. Apply the workarounds only when the use of HPET was not explicitly requested on the command line and when use of (deep) C-states was not disabled. Adjust a few types in touched or nearby code at the same time. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: d5294a302c8441191d47888452958aea25243723 master date: 2019-12-03 14:14:44 +0100 commit 55ca8abe77c77e4e91c3000892932b1156a50bdc Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Jan 15 14:22:22 2020 +0100 gnttab: make sure grant map operations don't skip their IOMMU part Two almost simultaneous mapping requests need to make sure that at the completion of the earlier one IOMMU mappings (established explicitly here in the PV case) have been put in place. Forever since the splitting of the grant table lock a violation of this has been possible (using simplified pin counts, as it doesn't matter whether we talk about read or write mappings here): initial state: act->pin = 0 vCPU A: progress the operation past the dropping of the locks after the act->pin updates (act->pin = 1, old_pin = 0, act_pin = 1) vCPU B: progress the operation past the dropping of the locks after the act->pin updates (act->pin = 2, old_pin = 1, act_pin = 2) vCPU B: (re-)acquire both gt locks, mapkind() returns 0, but both iommu_legacy_map() invocations get skipped due to non-zero old_pin vCPU B: return to caller without IOMMU mapping vCPU A: (re-)acquire both gt locks, mapkind() returns 0, iommu_legacy_map() gets invoked With the locks dropped intermediately, whether to invoke iommu_legacy_map() must depend on only the return value of mapkind() and of course the kind of mapping request being processed, just like is already the case in unmap_common(). Also fix the style of the adjacent comment, and correct a nearby one still referring to a prior name of what is now mapkind(). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 921f1f42260c7967bf18f8a143d39511d163c421 master date: 2019-12-03 14:13:40 +0100 commit cb071e4719c1fe07bba23bd82f3946f64c011967 Author: Julien Grall <jgrall@xxxxxxxxxx> Date: Wed Jan 15 14:21:14 2020 +0100 xen/x86: vpmu: Unmap per-vCPU PMU page when the domain is destroyed A guest will setup a shared page with the hypervisor for each vCPU via XENPMU_init. The page will then get mapped in the hypervisor and only released when XENPMU_finish is called. This means that if the guest fails to invoke XENPMU_finish, e.g if it is destroyed rather than cleanly shut down, the page will stay mapped in the hypervisor. One of the consequences is the domain can never be fully destroyed as a page reference is still held. As Xen should never rely on the guest to correctly clean-up any allocation in the hypervisor, we should also unmap such pages during the domain destruction if there are any left. We can re-use the same logic as in pvpmu_finish(). To avoid duplication, move the logic in a new function that can also be called from vpmu_destroy(). NOTE: - The call to vpmu_destroy() must also be moved from arch_vcpu_destroy() into domain_relinquish_resources() such that the reference on the mapped page does not prevent domain_destroy() (which calls arch_vcpu_destroy()) from being called. - Whilst it appears that vpmu_arch_destroy() is idempotent it is by no means obvious. Hence make sure the VPMU_CONTEXT_ALLOCATED flag is cleared at the end of vpmu_arch_destroy(). - This is not an XSA because vPMU is not security supported (see XSA-163). Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: be18e39d2f69038804b27c30026754deaeefa543 master date: 2019-11-29 18:23:24 +0000 commit efb9c6824454f40a86eda442eeec560471f5da51 Author: Julien Grall <julien@xxxxxxx> Date: Thu Dec 19 08:12:21 2019 +0000 xen/arm: Place a speculation barrier sequence following an eret instruction Some CPUs can speculate past an ERET instruction and potentially perform speculative accesses to memory before processing the exception return. Since the register state is often controlled by lower privilege level at the point of an ERET, this could potentially be used as part of a side-channel attack. Newer CPUs may implement a new SB barrier instruction which acts as an architected speculation barrier. For current CPUs, the sequence DSB; ISB is known to prevent speculation. The latter sequence is heavier than SB but it would never be executed (this is speculation after all!). Introduce a new macro 'sb' that could be used when a speculation barrier is required. For now it is using dsb; isb but this could easily be updated to cater SB in the future. This is XSA-312. Signed-off-by: Julien Grall <julien@xxxxxxx> (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |