|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.10-testing baseline-only test] 75577: tolerable FAIL
This run is configured for baseline tests only. flight 75577 xen-4.10-testing real [real] http://osstest.xensource.com/osstest/logs/75577/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail baseline untested test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail baseline untested test-amd64-amd64-i386-pvgrub 19 guest-start/debian.repeat fail baseline untested test-amd64-amd64-xl-qemuu-win10-i386 15 guest-saverestore.2 fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail baseline untested test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass test-armhf-armhf-xl-midway 12 guest-start fail never pass test-armhf-armhf-xl-multivcpu 12 guest-start fail never pass test-armhf-armhf-xl 12 guest-start fail never pass test-armhf-armhf-xl-credit2 12 guest-start fail never pass test-armhf-armhf-xl-rtds 12 guest-start fail never pass test-armhf-armhf-libvirt 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 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-credit1 12 guest-start fail never pass test-amd64-amd64-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-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-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-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 10 debian-di-install fail never pass test-armhf-armhf-xl-vhd 10 debian-di-install fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 5b15c049b526eadc9bee975a1188260e3543313d baseline version: xen 73788eb585a6dc0d0cfe18b03ba5154f8fe5c468 Last test of basis 75520 2018-10-27 09:48:36 Z 11 days Testing same since 75577 2018-11-07 04:18:39 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Wei Liu <wei.liu2@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 fail 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-amd64-amd64-xl-credit1 pass test-armhf-armhf-xl-credit1 fail test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail 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 fail 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 fail test-amd64-i386-libvirt pass test-armhf-armhf-xl-midway fail test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail 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 fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail 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 fail ------------------------------------------------------------ sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ------------------------------------------------------------ commit 5b15c049b526eadc9bee975a1188260e3543313d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 15:13:00 2018 +0100 x86/pv: Fix crash when using `xl set-parameter pcid=...` "pcid=" is registered as a runtime parameter, which means that parse_pcid() must not reside in .init, or the following happens when parse_params() tries to call an unmapped function pointer. (XEN) ----[ Xen-4.12-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff82d080407fb3>] ffff82d080407fb3 (XEN) RFLAGS: 0000000000010292 CONTEXT: hypervisor (d0v1) (XEN) rax: ffff82d080407fb3 rbx: ffff82d0803cf270 rcx: 0000000000000000 (XEN) rdx: ffff8300abe67fff rsi: 000000000000000a rdi: ffff8300abe67bfd (XEN) rbp: ffff8300abe67ca8 rsp: ffff8300abe67ba0 r8: ffff83084d980000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: ffff8300abe67bfd r13: ffff82d0803cb628 r14: 0000000000000000 (XEN) r15: ffff8300abe67bf8 cr0: 0000000080050033 cr4: 0000000000172660 (XEN) cr3: 0000000828efd000 cr2: ffff82d080407fb3 (XEN) fsb: 00007fb810d4b780 gsb: ffff88007ce20000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) Xen code around <ffff82d080407fb3> (ffff82d080407fb3) [fault on access]: (XEN) -- -- -- -- -- -- -- -- <--> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- (XEN) Xen stack trace from rsp=ffff8300abe67ba0: (XEN) ffff82d080217f61 ffff830826db0f09 ffff8300abe67bf8 ffff82d0803cf1e0 (XEN) 00007cff54198409 ffff8300abe67bf0 010001d000000000 0000000000000000 (XEN) ffff82d0803cf288 ffff8300abe67c88 ffff82d0805a09c0 616c620064696370 (XEN) 00000000aaaa0068 0000000000000296 ffff82d08023d60e aaaaaaaaaaaaaaaa (XEN) ffff83084d9b4000 ffff8300abe67c68 ffff82d08024940e ffff83083736e000 (XEN) 0000000000000080 000000000000007a 000000000000000a ffff82d08045e61c (XEN) ffff82d080573d80 ffff8300abe67cb8 ffff82d080249805 80000007fce54067 (XEN) fffffffffffffff2 ffff830826db0f00 ffff8300abfa7000 ffff82d08045e61c (XEN) ffff82d080573d80 ffff8300abe67cb8 ffff82d08021801e ffff8300abe67e48 (XEN) ffff82d08023f60a ffff83083736e000 0000000000000000 ffff8300abe67d58 (XEN) ffff82d080293d90 0000000000000092 ffff82d08023d60e ffff820040006ae0 (XEN) 0000000000000000 0000000000000000 00007fb810d5c010 ffff83083736e248 (XEN) 0000000000000286 ffff8300abe67d58 0000000000000000 ffff82e010521b00 (XEN) 0000000000000206 0000000000000000 0000000000000000 ffff8300abe67e48 (XEN) ffff82d080295270 00000000ffffffff ffff83083736e000 ffff8300abe67e48 (XEN) ffff820040006ae0 ffff8300abe67d98 000000120000001c 00007fb810d5d010 (XEN) 0000000000000009 0000000000000002 0000000000000001 00007fb810b53260 (XEN) 0000000000000001 0000000000000000 0000000000638bc0 00007fb81066a748 (XEN) 00007ffe11087881 0000000000000002 0000000000000001 00007fb810b53260 (XEN) 0000000000638b60 0000000000000000 00007fb8100322a0 ffff82d08035d444 (XEN) Xen call trace: (XEN) [<ffff82d080217f61>] kernel.c#parse_params+0x34a/0x3eb (XEN) [<ffff82d08021801e>] runtime_parse+0x1c/0x1e (XEN) [<ffff82d08023f60a>] do_sysctl+0x108d/0x1241 (XEN) [<ffff82d0803535cb>] pv_hypercall+0x1ac/0x4c5 (XEN) [<ffff82d08035d4a2>] lstar_enter+0x112/0x120 (XEN) (XEN) Pagetable walk from ffff82d080407fb3: (XEN) L4[0x105] = 00000000abe5c063 ffffffffffffffff (XEN) L3[0x142] = 00000000abe59063 ffffffffffffffff (XEN) L2[0x002] = 000000084d9bf063 ffffffffffffffff (XEN) L1[0x007] = 0000000000000000 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) FATAL PAGE FAULT (XEN) [error_code=0010] (XEN) Faulting linear address: ffff82d080407fb3 (XEN) **************************************** Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: f993c3e90728705dacd834b49a6e5608c1360409 master date: 2018-10-30 13:26:21 +0000 commit 6e3650dc204e0e274e23e769e8cae8695f28328c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 15:12:40 2018 +0100 tools/dombuilder: Initialise vcpu debug registers correctly In particular, initialising %dr6 with the value 0 is buggy, because on hardware supporting Transactional Memory, it will cause the sticky RTM bit to be asserted, even though a debug exception from a transaction hasn't actually been observed. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> master commit: 46029da12e5efeca6d957e5793bd34f2965fa0a1 master date: 2018-10-24 14:43:05 +0100 commit 4d5a0f2ffb91ca2be61d9ae42eb3f58b5ce9fff5 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 15:12:05 2018 +0100 x86/domain: Initialise vcpu debug registers correctly In particular, initialising %dr6 with the value 0 is buggy, because on hardware supporting Transactional Memory, it will cause the sticky RTM bit to be asserted, even though a debug exception from a transaction hasn't actually been observed. Introduce arch_vcpu_regs_init() to set various architectural defaults, and reuse this in the hvm_vcpu_reset_state() path. Architecturally, %edx's init state contains the processors model information, and 0xf looks to be a remnant of the old Intel processors. We clearly have no software which cares, seeing as it is wrong for the last decade's worth of Intel hardware and for all other vendors, so lets use the value 0 for simplicity. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> x86/domain: Fix build with GCC 4.3.x GCC 4.3.x can't initialise the user_regs structure like this. Reported-by: Jan Beulich <JBeulich@xxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: dfba4d2e91f63a8f40493c4fc2db03fd8287f6cb master date: 2018-10-24 14:43:05 +0100 master commit: 0a1fa635029d100d4b6b7eddb31d49603217cab7 master date: 2018-10-30 13:26:21 +0000 commit b0f1b24663b8c09bed7c3171385caad89d937428 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 15:11:10 2018 +0100 x86/boot: Initialise the debug registers correctly In particular, initialising %dr6 with the value 0 is buggy, because on hardware supporting Transactional Memory, it will cause the sticky RTM bit to be asserted, even though a debug exception from a transaction hasn't actually been observed. Move X86_DR6_DEFAULT into x86-defns.h along with the other architectural register constants, and introduce a new X86_DR7_DEFAULT. Use the existing write_debugreg() helper, rather than opencoded inline assembly. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> master commit: 721da6d41a70fe08b3fcd9c31a62f6709a54c6ba master date: 2018-10-24 14:43:05 +0100 commit aa05c39678a9b288a7ec48f8f58dc195ff7cdc46 Author: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Date: Mon Nov 5 15:10:42 2018 +0100 x86/boot: enable NMIs after traps init In certain scenarios, NMIs might be disabled during Xen boot process. Such situation will cause alternative_instructions() to: panic("Timed out waiting for alternatives self-NMI to hit\n"); This bug was originally seen when using Tboot to boot Xen 4.11 To prevent this from happening, enable NMIs during cpu_init() and during __start_xen() for BSP. Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 072e054359a4d4a4f6c3fa09585667472c4f0f1d master date: 2018-10-23 12:33:54 +0100 commit c504397642314cfa0c4ae32ea73368fc3dcc00a4 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Mon Nov 5 15:10:17 2018 +0100 vtd: add missing check for shared EPT... ...in intel_iommu_unmap_page(). This patch also includes some non-functional modifications in intel_iommu_map_page(). Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: e30c47cd8be8ba73cfc1ec7b1ebd036464708a24 master date: 2018-10-04 14:53:57 +0200 commit 16393521331dabea325381859c5107e1e4e94130 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 15:09:48 2018 +0100 x86: fix "xpti=" and "pv-l1tf=" yet again While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti= parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that this then became equivalent to "xpti=no". In particular, the presence of "xpti=" alone on the command line means nothing as to which default is to be overridden; "xpti=no-dom0", for example, ought to have no effect for DomU-s, as this is distinct from both "xpti=no-dom0,domu" and "xpti=no-dom0,no-domu". Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 8743d2dea539617e237c77556a91dc357098a8af master date: 2018-10-04 14:49:56 +0200 commit b79ac2746c4614e15e69266048d92be9b03194fd Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 15:09:16 2018 +0100 x86: split opt_pv_l1tf Use separate tracking variables for the hardware domain and DomU-s. No functional change intended, but adjust the comment in init_speculation_mitigations() to match prior as well as resulting code. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 0b89643ef6ef14e2c2b731ca675d23e405ed69b1 master date: 2018-10-04 14:49:19 +0200 commit 5822be6a6a5015670a5c726722d2d37c3531f6e4 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 15:08:47 2018 +0100 x86: split opt_xpti Use separate tracking variables for the hardware domain and DomU-s. No functional change intended. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 51e0cb45932d80d4eeb59994ee2c3f3c597b0212 master date: 2018-10-04 14:48:18 +0200 commit 225fbd2e25f570002b3be74efde9c23eb21e1251 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 15:08:00 2018 +0100 x86: silence false log messages for plain "xpti" / "pv-l1tf" While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti= parsing") claimed to have got rid of the 'parameter "xpti" has invalid value "", rc=-22!' log message for "xpti" alone on the command line, this wasn't the case (the option took effect nevertheless). Fix this there as well as for plain "pv-l1tf". Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 2fb57e4beefeda923446b73f88b392e59b07d847 master date: 2018-09-28 17:12:14 +0200 (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 |