* [xen-unstable-smoke test] 163385: regressions - trouble: blocked/fail
@ 2021-07-07 8:46 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2021-07-07 8:46 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 163385 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-build fail REGR. vs. 163326
build-arm64-xsm 6 xen-build fail REGR. vs. 163326
build-armhf 6 xen-build fail REGR. vs. 163326
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
version targeted for testing:
xen f17a73b3c0264c62dd6b5dae01ed621c051c3038
baseline version:
xen 4473f3601098a2c3cf5ab89d5a29504772985e3a
Last test of basis 163326 2021-07-06 09:01:40 Z 0 days
Testing same since 163328 2021-07-06 13:01:47 Z 0 days 13 attempts
------------------------------------------------------------
People who touched revisions under test:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Michal Orzel <michal.orzel@arm.com>
Olaf Hering <olaf@aepfle.de>
jobs:
build-arm64-xsm fail
build-amd64 fail
build-armhf fail
build-amd64-libvirt blocked
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm blocked
test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked
test-amd64-amd64-libvirt blocked
------------------------------------------------------------
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 f17a73b3c0264c62dd6b5dae01ed621c051c3038
Author: Olaf Hering <olaf@aepfle.de>
Date: Thu Jul 1 11:56:08 2021 +0200
tools/migration: unify type checking for data pfns in migration stream
Introduce a helper which decides if a given pfn type has data
in the migration stream.
No change in behaviour intended, except for invalid page types which now
have a safer default.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
commit 5588ebcfca774477cf823949e5703b0ac48818cc
Author: Olaf Hering <olaf@aepfle.de>
Date: Thu Jul 1 11:56:07 2021 +0200
tools/migration: unify type checking for data pfns in the VM
Introduce a helper which decides if a given pfn in the migration
stream is backed by memory.
This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a
synthetic toolstack-only type used between Xen 4.2 to 4.5 which
indicated a dirty page on the sending side for which no data will be
send in the initial iteration) does get populated in the VM.
No change in behaviour intended, except for invalid page types which now
have a safer default.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 9e59d9f8ee3808acde9833192211da25f66d8cc2
Author: Olaf Hering <olaf@aepfle.de>
Date: Thu Jul 1 11:56:05 2021 +0200
tools/migration: unify known page type checking
Users of xc_get_pfn_type_batch may want to sanity check the data
returned by Xen. Add helpers for this purpose:
is_known_page_type verifies the type returned by Xen on the saving
side, or the incoming type for a page on the restoring side, is known
by the save/restore code.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit a27976a1080d537fb1f212a8f9133d60daa0025b
Author: Olaf Hering <olaf@aepfle.de>
Date: Thu Jul 1 11:56:01 2021 +0200
tools/python: fix Python3.4 TypeError in format string
Using the first element of a tuple for a format specifier fails with
python3.4 as included in SLE12:
b = b"string/%x" % (i, )
TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
It happens to work with python 2.7 and 3.6.
To support older Py3, format as strings and explicitly encode as ASCII.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
commit c8f88810db2a25d6aacf65c1c60bc4f5d848a483
Author: Olaf Hering <olaf@aepfle.de>
Date: Thu Jul 1 11:56:00 2021 +0200
tools/python: handle libxl__physmap_info.name properly in convert-legacy-stream
The trailing member name[] in libxl__physmap_info is written as a
cstring into the stream. The current code does a sanity check if the
last byte is zero. This attempt fails with python3 because name[-1]
returns a type int. As a result the comparison with byte(\00) fails:
File "/usr/lib/xen/bin/convert-legacy-stream", line 347, in read_libxl_toolstack
raise StreamError("physmap name not NUL terminated")
StreamError: physmap name not NUL terminated
To handle both python variants, cast to bytearray().
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
commit 918b8842a852e0e7446286f546724b1c63c56c66
Author: Michal Orzel <michal.orzel@arm.com>
Date: Mon Jul 5 08:39:52 2021 +0200
arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
AArch64 registers are 64bit whereas AArch32 registers
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.
We should also use register_t type when reading sysregs
which can correspond to uint64_t or uint32_t.
Even though many AArch64 registers have upper 32bit reserved
it does not mean that they can't be widen in the future.
Modify type of hsr, cpsr, spsr_el1 to uint64_t.
Previously we relied on the padding after spsr_el1.
As we removed the padding, modify the union to be 64bit so we don't corrupt spsr_fiq.
No need to modify the assembly code because the accesses were based on 64bit
registers as there was a 32bit padding after spsr_el1.
Remove 32bit padding in cpu_user_regs before spsr_fiq
as it is no longer needed due to upper union being 64bit now.
Add 64bit padding in cpu_user_regs before spsr_el1
because the kernel frame should be 16-byte aligned.
Change type of cpsr to uint64_t in the public outside interface
"public/arch-arm.h" to allow ABI compatibility between 32bit and 64bit.
Increment XEN_DOMCTL_INTERFACE_VERSION.
Change type of cpsr to uint64_t in the public outside interface
"public/vm_event.h" to allow ABI compatibility between 32bit and 64bit.
Signed-off-by: Michal Orzel <michal.orzel@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
(qemu changes not included)
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-07-07 8:46 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-07 8:46 [xen-unstable-smoke test] 163385: regressions - trouble: blocked/fail osstest service owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).