|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.8-testing baseline-only test] 75593: tolerable FAIL
This run is configured for baseline tests only. flight 75593 xen-4.8-testing real [real] http://osstest.xensource.com/osstest/logs/75593/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail baseline untested test-armhf-armhf-xl 12 guest-start fail baseline untested test-armhf-armhf-xl-midway 12 guest-start fail baseline untested test-armhf-armhf-libvirt 12 guest-start fail baseline untested test-armhf-armhf-xl-credit2 12 guest-start fail baseline untested test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail baseline untested test-armhf-armhf-xl-multivcpu 12 guest-start fail baseline untested test-armhf-armhf-xl-rtds 12 guest-start fail baseline untested test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail baseline untested test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail baseline untested test-amd64-amd64-i386-pvgrub 10 debian-di-install fail baseline untested test-armhf-armhf-xl-vhd 10 debian-di-install fail baseline untested test-armhf-armhf-libvirt-raw 10 debian-di-install fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail baseline untested test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail baseline untested test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 12 guest-start fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install 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-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-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop 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 version targeted for testing: xen d6798ce35707a485d9c132319d70dd654620e5e5 baseline version: xen dee593780213a4997ae6206cc4d103e608613098 Last test of basis 75435 2018-10-16 20:46:52 Z 29 days Testing same since 75593 2018-11-14 13:49:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Olaf Hering <olaf@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-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-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-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-amd64-amd64-livepatch pass test-amd64-i386-livepatch 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 fail 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 d6798ce35707a485d9c132319d70dd654620e5e5 Author: Olaf Hering <olaf@xxxxxxxxx> Date: Mon Jun 18 14:55:36 2018 +0200 stubdom/vtpm: fix memcmp in TPM_ChangeAuthAsymFinish gcc8 spotted this error: error: 'memcmp' reading 20 bytes from a region of size 8 [-Werror=stringop-overflow=] Signed-off-by: Olaf Hering <olaf@xxxxxxxxx> Reviewed-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> (cherry picked from commit 22bf5be3237cb482a2ffd772ffd20ce37285eebf) (cherry picked from commit dea9fc0e02d92f5e6d46680aa0a52fa758eca9c4) (cherry picked from commit e907460fd61c350487ffee5d8aa375bef56bc81c) Conflicts: stubdom/Makefile Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit f13983db120f5e56dfefbee5d56678d2d43e2914) commit d792e577dcccced0cdce6e02c8f22249e55b81a5 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Nov 7 09:51:44 2018 +0100 x86: work around HLE host lockup erratum XACQUIRE prefixed accesses to the 4Mb range of memory starting at 1Gb are liable to lock up the processor. Disallow use of this memory range. Unfortunately the available Core Gen7 and Gen8 spec updates are pretty old, so I can only guess that they're similarly affected when Core Gen6 is and the Xeon counterparts are, too. This is part of XSA-282. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: cc76410d20aff2cc07b268b0713dc1d2740c6e12 master date: 2018-11-07 09:33:24 +0100 commit ba4eb853193e491a1a0bc0441dc6aba83668b43a Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Nov 7 09:50:58 2018 +0100 x86: extend get_platform_badpages() interface Use a structure so along with an address (now frame number) an order can also be specified. This is part of XSA-282. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 8617e69fb8307b372eeff41d55ec966dbeba36eb master date: 2018-11-07 09:32:08 +0100 commit 88b5e368ce08aaff78db5e3edc4c488945837750 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 16:17:56 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 64fd42fbcb3928454056ef2663d5b248cd8c3a84 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 16:17:26 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 86cba9b02366de10ee6beffe1ead8600ec68245f Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Nov 5 16:16:45 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 49f74ea609a61004c638e6ffc527bff769ce98ef Author: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Date: Mon Nov 5 16:16:19 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 5b6fb33d8f4fe753377090e6be8aaa816a6814ec Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Mon Nov 5 16:15: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 8d1afd1cef0f24c00b73d44fed53730b0bbcbb2e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 16:14:50 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 0dbe6acef093456a06fb489c911a602874208b20 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 16:14:25 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 38a7dded19e30f1cea620db46738ef39579517f5 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 16:13:55 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 bd89569fb525ec957beb798ec99a2bb77de6bc94 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 5 16:13:09 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 |