|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 171506: regressions - FAIL
flight 171506 xen-unstable-smoke real [real] flight 171508 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/171506/ http://logs.test-lab.xenproject.org/osstest/logs/171508/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 171486 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 61ff2733221e3b5bae5f647d9a460c7a68a5ace8 baseline version: xen 4df2e99d731402da48afb19dc970ccab5a0814d6 Last test of basis 171486 2022-07-04 13:00:25 Z 1 days Failing since 171501 2022-07-05 12:03:08 Z 0 days 2 attempts Testing same since 171506 2022-07-05 17:00:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD <anthony.perard@xxxxxxxxxx> Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <jgrall@xxxxxxxxxx> Luca Fancellu <luca.fancellu@xxxxxxx> Michal Orzel <michal.orzel@xxxxxxx> Roger Pau Monne <roger.pau@xxxxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Wei Chen <wei.chen@xxxxxxx> jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ 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 61ff2733221e3b5bae5f647d9a460c7a68a5ace8 Author: Michal Orzel <michal.orzel@xxxxxxx> Date: Mon Jun 27 15:15:39 2022 +0200 xen/common: Use unsigned int instead of plain unsigned This is just for the style and consistency reasons as the former is being used more often than the latter. Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx> Reviewed-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 54d8f27d0477937e1f99a414fc1ffd93d184b38a Author: Roger Pau Monne <roger.pau@xxxxxxxxxx> Date: Fri Apr 8 10:21:11 2022 +0200 tools/libxl: report trusted backend status to frontends Allow administrators to notify a frontend driver that it's backend counterpart is not to be trusted, so the frontend can deploy whatever mitigations required in order to secure itself. Allow such option for disk and network frontends only, as those are the only hardened ones currently supported. This is part of XSA-403 Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> commit a4d4c541f58b378bc9d499dcb554eb9fe22312c8 Author: Wei Chen <wei.chen@xxxxxxx> Date: Tue Jul 5 13:12:15 2022 +0200 xen/arm32: avoid EFI stub wchar_t size linker warning Xen uses "-fshort-wchar" in CFLAGS for EFI common code. Arm32 is using stub.c of EFI common code for EFI stub functions. But "-fshort-wchar" CFLAG will cause a warning when build stub.c for Arm32: "arm-linux-gnueabihf-ld: warning: arch/arm/efi/built_in.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail" This is because the "-fshort-wchar" flag causes GCC to generate code that is not binary compatible with code generated without that flag. Why this warning hasn't been triggered in Arm64 is because Arm64 does not use wchar type directly in any code for parameters, variables and return values. And in EFI code, wchar has been replaced by CHAR16 (the UEFI "abstraction" of wchar_t). CHAR16 has been specified as unsigned short type in typedef, the "-fshort-wchar" flag will not affect CHAR16. So Arm64 object files are exactly the same with "-fshort-wchar" and without "-fshort-wchar". We are also not using wchar in Arm32 codes, but Arm32 will embed ABI information in ".ARM.attributes" section. This section stores some object file attributes, like ABI version, CPU arch and etc. And wchar size is described in this section by "Tag_ABI_PCS_wchar_t" too. Tag_ABI_PCS_wchar_t is 2 for object files with "-fshort-wchar", but for object files without "-fshort-wchar" is 4. Arm32 GCC ld will check this tag, and throw above warning when it finds the object files have different Tag_ABI_PCS_wchar_t values. Xen need to keep "-fshort-wchar" in EFI code to force wchar to use short integers (2 bytes) instead of integers (4 bytes), but this is unnecessary for code out of EFI. So in this patch, we add "-fno-short-wchar" to override "-fshort-wchar" for Arm architectures without EFI enabled to remove above warning." Reported-and-Suggested-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Jan Beulich <jbeulich@xxxxxxxx> Signed-off-by: Wei Chen <wei.chen@xxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <jgrall@xxxxxxxxxx> commit c4184bf305dc14c3e150617904c40b120664efe6 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jul 5 13:11:51 2022 +0200 public: constify xsd_errors[] While in principle this could break existing users, I think such users deserve to be put in trouble. After all the table should have been const from the very beginning. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Juergen Gross <jgross@xxxxxxxx> commit 2b1ee386122a6e8bf66f5163cbda51084af6e0f4 Author: Luca Fancellu <luca.fancellu@xxxxxxx> Date: Tue Jul 5 13:11:25 2022 +0200 tools/helpers: fix snprintf argument in init-dom0less.c Fix snprintf argument in init-dom0less.c because two instances of the function are using libxl_dominfo struct members that are uint64_t types, so change "%lu" to "%"PRIu64 to handle it properly when building on arm32 and arm64. Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx> Acked-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> commit 8d410ac2c178e1dd1001cadddbe9ca75a9738c95 Author: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> Date: Tue Jul 5 13:10:46 2022 +0200 EFI: preserve the System Resource Table for dom0 The EFI System Resource Table (ESRT) is necessary for fwupd to identify firmware updates to install. According to the UEFI specification §23.4, the ESRT shall be stored in memory of type EfiBootServicesData. However, memory of type EfiBootServicesData is considered general-purpose memory by Xen, so the ESRT needs to be moved somewhere where Xen will not overwrite it. Copy the ESRT to memory of type EfiRuntimeServicesData, which Xen will not reuse. dom0 can use the ESRT if (and only if) it is in memory of type EfiRuntimeServicesData. Earlier versions of this patch reserved the memory in which the ESRT was located. This created awkward alignment problems, and required either splitting the E820 table or wasting memory. It also would have required a new platform op for dom0 to use to indicate if the ESRT is reserved. By copying the ESRT into EfiRuntimeServicesData memory, the E820 table does not need to be modified, and dom0 can just check the type of the memory region containing the ESRT. The copy is only done if the ESRT is not already in EfiRuntimeServicesData memory, avoiding memory leaks on repeated kexec. See https://lore.kernel.org/xen-devel/20200818184018.GN1679@mail-itl/T/ for details. Signed-off-by: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |