[xen-unstable-smoke test] 136453: regressions

* [xen-unstable-smoke test] 136453: regressions - FAIL
@ 2019-05-17 17:56 ` osstest service owner
  0 siblings, 0 replies; 2+ messages in thread
From: osstest service owner @ 2019-05-17 17:56 UTC (permalink / raw)
  To: xen-devel, osstest-admin

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@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Wei Liu <wei.liu2@citrix.com>

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@citrix.com>
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@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 346666c4bdf72ca1d908bbcdb9185981aac7e749
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 4e069d60937b9cbffc3185f4e059f5dcc99e4cb0
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 76d8dd2705a091078c871dff2024953749606dd0
Author: Jan Beulich <jbeulich@suse.com>
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@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit 582a298b215088acb042793da91f0baa8ce34425
Author: Anthony PERARD <anthony.perard@citrix.com>
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@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

commit ffd3367ed682b6ac6f57fcb151921054dd4cce7e
Author: Juergen Gross <jgross@suse.com>
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@suse.com>
    Reviewed-by: Dario Faggioli <dfaggioli@suse.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread