flight 127228 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/127228/
Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 127212 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 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 version targeted for testing: xen a9a2a761f75126d908612c64fabe6adde2b6d2b9 baseline version: xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd Last test of basis 127212 2018-09-03 13:00:29 Z 0 days Failing since 127215 2018-09-03 16:00:27 Z 0 days 4 attempts Testing same since 127219 2018-09-03 19:00:33 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.coop...@citrix.com> Jan Beulich <jbeul...@suse.com> Razvan Cojocaru <rcojoc...@bitdefender.com> Roger Pau Monné <roger....@citrix.com> Tim Deegan <t...@xen.org> 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 pass test-amd64-amd64-xl-qemuu-debianhvm-i386 fail 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9 Author: Andrew Cooper <andrew.coop...@citrix.com> Date: Wed Aug 1 13:48:33 2018 +0000 x86/hvm: Fix mapping corner case during task switching hvm_map_entry() can fail for a number of reasons, including for a misaligned LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this should be fixed, but Long Mode doesn't support task switches, and no 32bit OS is going to misalign its LDT/GDT base, which is why this task isn't very high on the TODO list. However, the hvm_map_fail error label returns failure without raising an exception, which interferes with hvm_task_switch()'s exception tracking, and can cause it to finish and return to guest context as if the task switch had completed successfully. Resolve this corner case by folding all the failure paths together, which causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry() copes fine with a NULL pointer so can be called unconditionally. In practice, this is just a latent corner case as all hvm_map_entry() failures crash the domain, but it should be fixed nevertheless. Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to avoid giving the impression that it is usable for general segment loading. Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Jan Beulich <jbeul...@suse.com> commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a Author: Andrew Cooper <andrew.coop...@citrix.com> Date: Wed Jan 24 16:43:55 2018 +0000 x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers Unlike the PRINTK/DEBUG wrappers, these go straight out to the console, rather than ending up in the debugtrace buffer. A number of these users are followed by domain_crash(), and future changes will want to combine the printk() into the domain_crash() call. Expand these wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before a domain_crash(). Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and explicitly drop some calls which are unnecessary (bad shadow op, and the empty stubs for incorrect sh_map_and_validate_gl?e() calls). Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Wei Liu <wei.l...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702 Author: Andrew Cooper <andrew.coop...@citrix.com> Date: Mon Sep 3 17:45:52 2018 +0100 xen/x86: Ignore the automatically generated include/asm-x86/asm-macros.h Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Wei Liu <wei.l...@citrix.com> commit 09b3907f93fe023ebca809c9f706f3d022801dce Author: Roger Pau Monné <roger....@citrix.com> Date: Mon Sep 3 17:54:12 2018 +0200 The hvmloader binary generated when using LLVM LD doesn't work properly and seems to get stuck while trying to generate and load the ACPI tables. This is caused by the layout of the binary when linked with LLVM LD. LLVM LD has a different default linker script that GNU LD, and the resulting hvmloader binary is slightly different: LLVM LD: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x000ff034 0x000ff034 0x00060 0x00060 R 0x4 LOAD 0x000000 0x000ff000 0x000ff000 0x38000 0x38000 RWE 0x1000 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0 GNU LD: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x00100000 0x00100000 0x36308 0x3fd74 RWE 0x10 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 Note that in the LLVM LD case (as with GNU LD) the .text section does indeed have the address set to 0x100000 as requested on the command line: [ 1] .text PROGBITS 00100000 001000 00dd10 00 AX 0 0 16 There's however the PHDR which is not present when using GNU LD. Fix this by using a very simple linker script that generates the same binary regardless of whether LLVM or GNU LD is used. By using a linker script the usage of -Ttext can also be avoided by placing the desired .text load address directly in the linker script. Signed-off-by: Roger Pau Monné <roger....@citrix.com> Reviewed-by: Wei Liu <wei.l...@citrix.com> Acked-by: Jan Beulich <jbeul...@suse.com> commit 936b77255269b3b9b5685d565550e77d5080ac81 Author: Jan Beulich <jbeul...@suse.com> Date: Mon Sep 3 17:51:40 2018 +0200 x86/boot: silence MADT table entry logging Logging disabled LAPIC / x2APIC entries with invalid local APIC IDs (ones having "broadcast" meaning when used) isn't very useful, and can be quite noisy on larger systems. Suppress their logging unless opt_cpu_info is true. Signed-off-by: Jan Beulich <jbeul...@suse.com> Acked-by: Andrew Cooper <andrew.coop...@citrix.com> commit 3f2002614af51dfd507168a1696658bac91155ce Author: Jan Beulich <jbeul...@suse.com> Date: Mon Sep 3 17:50:10 2018 +0200 x86: assorted array_index_nospec() insertions Don't chance having Spectre v1 (including BCBS) gadgets. In some of the cases the insertions are more of precautionary nature rather than there provably being a gadget, but I think we should err on the safe (secure) side here. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Paul Durrant <paul.durr...@citrix.com> Acked-by: Razvan Cojocaru <rcojoc...@bitdefender.com> Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel