* [xen-4.8-testing baseline-only test] 72211: regressions - trouble: blocked/broken/fail/pass
@ 2017-10-07 15:27 Platform Team regression test user
0 siblings, 0 replies; only message in thread
From: Platform Team regression test user @ 2017-10-07 15:27 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 72211 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win10-i386 16 guest-localmigrate/x10 fail REGR. vs. 72102
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops 2 hosts-allocate broken never pass
build-arm64-xsm 2 hosts-allocate broken never pass
build-arm64 3 capture-logs broken never pass
build-arm64-pvops 3 capture-logs broken never pass
build-arm64-xsm 3 capture-logs broken never pass
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail blocked in 72102
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 72102
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 72102
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 72102
build-amd64-prev 7 xen-build/dist-test fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 12 guest-start fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-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-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 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 10 windows-install fail never pass
test-armhf-armhf-xl-midway 13 migrate-support-check fail never pass
test-armhf-armhf-xl-midway 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-amd64-amd64-xl-pvh-amd 12 guest-start fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-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-amd64-amd64-libvirt-xsm 13 migrate-support-check 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
build-i386-prev 7 xen-build/dist-test 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-amd64-qemuu-nested-intel 18 capture-logs/l1(18) fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop fail never pass
version targeted for testing:
xen 2116fec45de00f59621cd4adb0641a8784b48faa
baseline version:
xen 36898eb12572f0a1f85cb54d4a9e90afcb6f7045
Last test of basis 72102 2017-09-13 14:50:31 Z 24 days
Testing same since 72211 2017-10-07 07:44:24 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Chao Gao <chao.gao@intel.com>
Crawford, Eric R <Eric.R.Crawford@intel.com>
David Woodhouse <dwmw@amazon.co.uk>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Stefano Stabellini <sstabellini@kernel.org>
Xiong Zhang <xiong.y.zhang@intel.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm broken
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 broken
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt blocked
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops broken
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-arm64-arm64-xl blocked
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-arm64-arm64-libvirt-xsm blocked
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm blocked
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-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-credit2 pass
test-arm64-arm64-xl-credit2 blocked
test-armhf-armhf-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
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-pvh-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 pass
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-armhf-armhf-xl-midway 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-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-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
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.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-xsm hosts-allocate
broken-step build-arm64 capture-logs
broken-step build-arm64-pvops capture-logs
broken-step build-arm64-xsm capture-logs
Push not applicable.
------------------------------------------------------------
commit 2116fec45de00f59621cd4adb0641a8784b48faa
Author: Julien Grall <julien.grall@arm.com>
Date: Fri Oct 6 15:06:54 2017 +0200
xen/arm: Correctly report the memory region in the dummy NUMA helpers
NUMA is currently not supported on Arm. Because common code is
NUMA-aware, dummy helpers are instead provided to expose a single node.
Those helpers are for instance used to know the region to scrub.
However the memory region is not reported correctly. Indeed, the
frametable may not be at the beginning of the memory and there might be
multiple memory banks. This will lead to not scrub some part of the
memory.
The memory information can be found using:
* first_valid_mfn as the start of the memory
* max_page - first_valid_mfn as the spanned pages
Note that first_valid_mfn is now been exported. The prototype has been
added in asm-arm/numa.h and not in a common header because I would
expect the variable to become static once NUMA is fully supported on
Arm.
This is XSA-245.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
master commit: 5414ba7f5e1ffc88ed2758b1e1b14bbfd3536a61
master date: 2017-09-29 13:23:11 -0700
commit 1a535c3614a4b35e5e94c4bdeaf08d4685d2435e
Author: Julien Grall <julien.grall@arm.com>
Date: Fri Oct 6 15:06:23 2017 +0200
xen/page_alloc: Cover memory unreserved after boot in first_valid_mfn
On Arm, some regions (e.g Initramfs, Dom0 Kernel...) are marked as
reserved until the hardware domain is built and they are copied into its
memory. Therefore, they will not be added in the boot allocator via
init_boot_pages.
Instead, init_xenheap_pages will be called once the region are not used
anymore.
Update first_valid_mfn in both init_heap_pages and init_boot_pages
(already exist) to cover all the cases.
This is XSA-245.
Signed-off-by: Julien Grall <julien.grall@arm.com>
[Adjust comment, added locking around first_valid_mfn update]
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
master commit: ec6d9023e1f54cdccbf2e4c63cf947f1be2b1e8e
master date: 2017-09-29 13:22:52 -0700
commit ee3fc2417755e1893f4486eb1893dff7fe5fcd19
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Oct 6 15:05:38 2017 +0200
x86: introduce and use setup_force_cpu_cap()
For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
need to clone the respective hack used for CPUID_FAULTING. Introduce an
inverse of setup_clear_cpu_cap() instead, but let clearing of features
overrule forced setting of them.
XEN_SMAP being wrong post-boot is a problem specifically for live
patching, as a live patch may need alternative instruction patching
keyed off of that feature flag.
Reported-by: Sarah Newman <security@prgmr.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 0829a6bdbdc6b79990bd0668e847275b6a2717e5
master date: 2017-09-06 12:32:00 +0200
commit d623d820c8ab55aca3e555aef3a90ab12f2d6573
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri Oct 6 15:05:03 2017 +0200
x86/emul: Fix the handling of unimplemented Grp7 instructions
Grp7 is abnormally complicated to decode, even by x86's standards, with
{s,l}msw being the problematic cases.
Previously, any value which fell through the first switch statement (looking
for instructions with entirely implicit operands) would be interpreted by the
second switch statement (handling instructions with memory operands).
Unimplemented instructions would then hit the #UD case for having a non-memory
operand, rather than taking the cannot_emulate path.
Consolidate the two switch statements into a single one, using ranges to cover
the instructions with memory operands.
Reported-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
master commit: 4d3f0fde471e7588ce512eaff1abdab209d8cd4b
master date: 2017-09-05 12:58:47 +0100
commit dda458cbd4249e425198bfdfaec2788367eae6a8
Author: Chao Gao <chao.gao@intel.com>
Date: Fri Oct 6 15:04:29 2017 +0200
VT-d: use correct BDF for VF to search VT-d unit
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
are under the scope of the same VT-d unit as the 'Physical Function'.
A 'Physical Function' can be a 'Traditional Function' or an ARI
'Extended Function'. And furthermore, 'Extended Functions' on an
endpoint are under the scope of the same VT-d unit as the 'Traditional
Functions' on the endpoint. To search VT-d unit for a VF, if its PF
isn't an extended function, the BDF of PF should be used. Otherwise
the BDF of a traditional function in the same device with the PF
should be used.
Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'.
But it is conceptually wrong w/o checking whether PF is an extended
function and would lead to match VFs of a RC integrated PF to a wrong
VT-d unit.
This patch overrides VF 'is_extfn' field and uses this field to
indicate whether the PF of this VF is an extended function. The field
helps to use correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
master commit: c286af54c7177c14180121b422d8df7281e547cb
master date: 2017-09-01 11:02:23 +0200
commit c642b12321d426df1efb2284ad1025c06bfcbdd4
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date: Fri Oct 6 15:04:09 2017 +0200
hvmloader: use base instead of pci_mem_start for find_next_rmrr()
find_next_rmrr(base) is used to find the lowest RMRR ending above base
but below 4G. Current method couldn't cover the following situation:
a. two rmrr exist, small gap between them
b. pci_mem_start and mem_resource.base is below the first rmrr.base
c. find_next_rmrr(pci_mem_start) will find the first rmrr
d. After aligning mem_resource.base to bar size,
first_rmrr.end < new_base < second_rmrr.base and
new_base + bar_sz > second_rmrr.base.
So the new bar will overlap with the second rmrr and doesn't overlap
with the first rmrr.
But the next_rmrr point to the first rmrr, then check_overlap() couldn't
find the overlap. Finally assign a wrong address to bar.
This patch using aligned new base to find the next rmrr, could fix the
above case and find all the overlapped rmrr with new base.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: ecc607b1851bc27140090da4d6124fd00090ec2b
master date: 2017-08-28 10:51:24 +0200
commit 80d7ef34e9ab826af10d786aa7ab1b0e9e0dac25
Author: David Woodhouse <dwmw@amazon.co.uk>
Date: Fri Oct 6 15:03:19 2017 +0200
x86/efi: don't write relocations in efi_arch_relocate_image() first pass
The function is invoked with delta=0 before ExitBootServices() is called,
as a dummy run purely to validate that all the relocations can be handled.
This allows us to exit gracefully with an error message.
However, we have relocations in read-only sections such as .rodata and
.init.te(xt). Recent versions of UEFI will actually make those sections
read-only, which will cause a fault. This functionaity was added in
EDK2 commit d0e92aad4 ("MdeModulePkg/DxeCore: Add UEFI image protection.")
It's OK to actually make the changes in the later pass because UEFI will
tear down the protection when ExitBootServices() is called, because it
knows we're going to need to do this kind of thing.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
master commit: 34828425d36b560adfe96430b9b83dfb0f66f2a8
master date: 2017-08-25 14:07:40 +0200
commit ff4f60a5c5f2279f321cdb7ee42d00f654915e62
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Oct 6 15:02:44 2017 +0200
x86: check for allocation errors in modify_xen_mappings()
Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: e466ec4f51d38a2c9d02bf9f3d5e43e47db2d66b
master date: 2017-08-25 14:03:47 +0200
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2017-10-07 15:27 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-07 15:27 [xen-4.8-testing baseline-only test] 72211: regressions - trouble: blocked/broken/fail/pass Platform Team regression test user
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.