[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 163351: regressions - trouble: blocked/fail
flight 163351 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163351/ 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 5 attempts ------------------------------------------------------------ People who touched revisions under test: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Michal Orzel <michal.orzel@xxxxxxx> Olaf Hering <olaf@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Juergen Gross <jgross@xxxxxxxx> commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering <olaf@xxxxxxxxx> 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@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering <olaf@xxxxxxxxx> 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@xxxxxxxxx> Reviewed-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering <olaf@xxxxxxxxx> 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@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> commit c8f88810db2a25d6aacf65c1c60bc4f5d848a483 Author: Olaf Hering <olaf@xxxxxxxxx> 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@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> commit 918b8842a852e0e7446286f546724b1c63c56c66 Author: Michal Orzel <michal.orzel@xxxxxxx> 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@xxxxxxx> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx> Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx> (qemu changes not included)
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |