|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 136453: regressions - FAIL
flight 136453 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/136453/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 136442 Tests which did not succeed, but are not blocking: 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 ae0e5f204cb42440e244419e6a92f7fd90eb25bb baseline version: xen 9cf11fdcd91ff8e9cd038f8336cf21f0701e8b7b Last test of basis 136442 2019-05-17 13:00:44 Z 0 days Testing same since 136453 2019-05-17 16:01:07 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Anthony PERARD <anthony.perard@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> 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 ae0e5f204cb42440e244419e6a92f7fd90eb25bb Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Jul 19 16:40:06 2018 +0000 x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid() They are identical, so provide a single x86emul_cpuid() instead. As x86_emulate() now only uses the ->cpuid() hook for real CPUID instructions, the hook can be omitted from all special-purpose emulation ops. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 346666c4bdf72ca1d908bbcdb9185981aac7e749 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Jul 19 15:57:41 2018 +0000 x86/emul: Don't use the ->cpuid() hook for feature checks For a release build of xen, this removes nearly 5k of code volume, and removes a function pointer call from every instantiation. add/remove: 0/1 grow/shrink: 0/3 up/down: 0/-4822 (-4822) Function old new delta adjust_bnd 260 244 -16 x86_decode 8915 8890 -25 vcpu_has.isra 129 - -129 x86_emulate 130040 125388 -4652 Total: Before=3326565, After=3321743, chg -0.14% Note that one corner case changes. At the moment, it is possible for an entity making direct DOMCTL_set_cpuid hypercalls to construct a policy with max_leaf < 7, but feature bits set in leaf 7. By default, libxc and libxl don't do this, and the result is properly bounded by what the hardware is capable of (so we won't start trying to use instructions which don't exist in the CPU). Previously, the cpuid() hook would end up hiding these features, but they may still be set cpuid_policy, and therefore might start being accepted by x86_emulate(). This corner case will be fixed by the in-progress DOMCTL_set_cpu_policy work, and a guest would only encounter the corner case if it was constructed in a non-standard manner, and if tried using instruction which it couldn't see CPUID feature bits for. As such, it isn't a corner case which we need to worry about. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 4e069d60937b9cbffc3185f4e059f5dcc99e4cb0 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Jul 19 15:52:06 2018 +0000 x86/emul: Pass a full cpuid_policy into x86_emulate() This will be used to simplify feature checking. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 76d8dd2705a091078c871dff2024953749606dd0 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 17 17:32:20 2019 +0200 x86: cover for clang's lack of support of -mpreferred-stack-boundary=<N> While clang supposedly supports -mstack-alignment=<N> instead, I'm not using that alternative here due to being uncertain whether that's indeed an exact equivalent of the gcc option. Only make use of the option entirely conditional for now. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 582a298b215088acb042793da91f0baa8ce34425 Author: Anthony PERARD <anthony.perard@xxxxxxxxxx> Date: Fri May 17 12:38:43 2019 +0100 libxc: elf_kernel loader: Remove check for shstrtab This was probably useful as a sanity check when the "__xen_guest" section were not legacy. But now ELF notes are prefered and "should live in a PT_NOTE segment" (elfnote.h). This check is unnecessary as elf_xen_parse() from xen/common/libelf will do the right thing and look for ELFNOTEs in the different places in order of preference. elf_xen_parse() will still be able to also look for the legacy "__xen_guest" section without the check in libxc. This patch would allow to write a simpler ELF header for an OVMF blob (which isn't an ELF) and allow it to be loaded as a PVH kernel. The header only needs to declare two program segments: - one to tell an ELF loader where to put the blob, - one for a Xen ELFNOTE. The ELFNOTE is to comply to the pvh design which wants the XEN_ELFNOTE_PHYS32_ENTRY to declare a blob as compaptible with the PVH boot ABI. Note that without the ELFNOTE, libxc will load an ELF but with the plain ELF loader, which doesn't check for shstrtab. Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit ffd3367ed682b6ac6f57fcb151921054dd4cce7e Author: Juergen Gross <jgross@xxxxxxxx> Date: Fri May 17 15:41:17 2019 +0200 xen/sched: fix csched2_deinit_pdata() Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling") introduced a regression when switching cpus between cpupools. When assigning a cpu to a cpupool with credit2 being the default scheduler csched2_deinit_pdata() is called for the credit2 private data after the new scheduler's private data has been hooked to the per-cpu scheduler data. Unfortunately csched2_deinit_pdata() will cycle through all per-cpu scheduler areas it knows of for removing the cpu from the respective sibling masks including the area of the just moved cpu. This will (depending on the new scheduler) either clobber the data of the new scheduler or in case of sched_rt lead to a crash. Avoid that by removing the cpu from the list of active cpus in credit2 data first. The opposite problem is occurring when removing a cpu from a cpupool: init_pdata() of credit2 will access the per-cpu data of the old scheduler. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: Dario Faggioli <dfaggioli@xxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |