[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen-unstable-smoke test] 162544: regressions - FAIL

flight 162544 xen-unstable-smoke real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 162327

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      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-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                  aad7b5c11d51d57659978e04702ac970906894e8
baseline version:
 xen                  5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1

Last test of basis   162327  2021-06-01 16:01:37 Z    6 days
Failing since        162370  2021-06-04 17:01:35 Z    3 days   26 attempts
Testing same since   162544  2021-06-08 12:00:27 Z    0 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Anthony PERARD <anthony.perard@xxxxxxxxxx>
  Christian Lindig <christian.lindig@xxxxxxxxxx>
  Dario Faggioli <dfaggioli@xxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxx>
  Ian Jackson <iwj@xxxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Wei Liu <wl@xxxxxxx>

 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 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

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit aad7b5c11d51d57659978e04702ac970906894e8
Author: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Date:   Tue Jun 1 11:28:03 2021 +0100

    tools/firmware/ovmf: Use OvmfXen platform file is exist
    A platform introduced in EDK II named OvmfXen is now the one to use for
    Xen instead of OvmfX64. It comes with PVH support.
    Also, the Xen support in OvmfX64 is deprecated,
        "deprecation notice: *dynamic* multi-VMM (QEMU vs. Xen) support in 
    Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
    Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>

commit d21121685fac829c988e432407fb0e4ef9b19331
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Mon Jun 7 15:00:05 2021 +0200

    tools/libs/guest: fix save and restore of pv domains after 32-bit de-support
    After 32-bit PV-guests have been security de-supported when not running
    under PV-shim, the hypervisor will no longer be configured to support
    those domains per default when not being built as PV-shim.
    Unfortunately libxenguest will fail saving or restoring a PV domain
    due to this restriction, as it is trying to get the compat MFN list
    even for 64 bit guests.
    Fix that by obtaining the compat MFN list only for 32-bit PV guests.
    Fixes: 1a0f2fe2297d122a08fe ("SUPPORT.md: Un-shimmed 32-bit PV guests are 
no longer supported")
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 69e1472d21cf7e5cf0795ef38b99d00de78a910e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Jun 7 13:38:53 2021 +0100

    x86/cpuid: Drop special_features[]
    While the ! annotation is useful to indicate that something special is
    happening, an array of bits is not.  Drop it, to prevent mistakes.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 60fa12dbf1d4d2c4ffe1ef34b495b24aa7e41aa0
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Jun 7 13:25:09 2021 +0100

    x86/cpuid: Fix HLE and RTM handling (again)
    For reasons which are my fault, but I don't recall why, the
    FDP_EXCP_ONLY/NO_FPU_SEL adjustment uses the whole special_features[] array
    element, not the two relevant bits.
    HLE and RTM were recently added to the list of special features, causing 
    to be always set in guest view, irrespective of the toolstacks choice on the
    Rewrite the logic to refer to the features specifically, rather than relying
    on the contents of the special_features[] array.
    Fixes: 8fe24090d9 ("x86/cpuid: Rework HLE and RTM handling")
    Reported-by: Edwin Török <edvin.torok@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit c4beefcada0a406681dcfb6e89f6cbe4aa368c2d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Jun 7 15:40:55 2021 +0200

    docs: release-technician-checklist: update to leaf tree version pinning
    Our releases look to flip-flop between keeping or discarding the date
    and title of the referenced qemu-trad commit. I think with the hash
    replaced by a tag, the commit's date and title would better also be
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>

commit 89052b9fa24bf976924e40918fc9fa3b1b940e17
Author: Dario Faggioli <dfaggioli@xxxxxxxx>
Date:   Fri Mar 19 12:14:17 2021 +0000

    xen: credit2: fix per-entity load tracking when continuing running
    If we schedule, and the current vCPU continues to run, its statistical
    load is not properly updated, resulting in something like this, even if
    all the 8 vCPUs are 100% busy:
    (XEN) Runqueue 0:
    (XEN) [...]
    (XEN)   aveload            = 2097152 (~800%)
    (XEN) [...]
    (XEN)   Domain: 0 w 256 c 0 v 8
    (XEN)     1: [0.0] flags=2 cpu=4 credit=9996885 [w=256] load=35 (~0%)
    (XEN)     2: [0.1] flags=2 cpu=2 credit=9993725 [w=256] load=796 (~0%)
    (XEN)     3: [0.2] flags=2 cpu=1 credit=9995885 [w=256] load=883 (~0%)
    (XEN)     4: [0.3] flags=2 cpu=5 credit=9998833 [w=256] load=487 (~0%)
    (XEN)     5: [0.4] flags=2 cpu=6 credit=9998942 [w=256] load=1595 (~0%)
    (XEN)     6: [0.5] flags=2 cpu=0 credit=9994669 [w=256] load=22 (~0%)
    (XEN)     7: [0.6] flags=2 cpu=7 credit=9997706 [w=256] load=0 (~0%)
    (XEN)     8: [0.7] flags=2 cpu=3 credit=9992440 [w=256] load=0 (~0%)
    As we can see, the average load of the runqueue as a whole is, instead,
    computed properly.
    This issue would, in theory, potentially affect Credit2 load balancing
    logic. In practice, however, the problem only manifests (at least with
    these characteristics) when there is only 1 runqueue active in the
    cpupool, which also means there is no need to do any load-balancing.
    Hence its real impact is pretty much limited to wrong per-vCPU load
    percentages, when looking at the output of the 'r' debug-key.
    With this patch, the load is updated and displayed correctly:
    (XEN) Runqueue 0:
    (XEN) [...]
    (XEN)   aveload            = 2097152 (~800%)
    (XEN) [...]
    (XEN) Domain info:
    (XEN)   Domain: 0 w 256 c 0 v 8
    (XEN)     1: [0.0] flags=2 cpu=4 credit=9995584 [w=256] load=262144 (~100%)
    (XEN)     2: [0.1] flags=2 cpu=6 credit=9992992 [w=256] load=262144 (~100%)
    (XEN)     3: [0.2] flags=2 cpu=3 credit=9998918 [w=256] load=262118 (~99%)
    (XEN)     4: [0.3] flags=2 cpu=5 credit=9996867 [w=256] load=262144 (~100%)
    (XEN)     5: [0.4] flags=2 cpu=1 credit=9998912 [w=256] load=262144 (~100%)
    (XEN)     6: [0.5] flags=2 cpu=2 credit=9997842 [w=256] load=262144 (~100%)
    (XEN)     7: [0.6] flags=2 cpu=7 credit=9994623 [w=256] load=262144 (~100%)
    (XEN)     8: [0.7] flags=2 cpu=0 credit=9991815 [w=256] load=262144 (~100%)
    Signed-off-by: Dario Faggioli <dfaggioli@xxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 07b0eb5d0ef0be154606aa46b5b4c5c59b158505
Author: Dario Faggioli <dfaggioli@xxxxxxxx>
Date:   Fri May 28 17:12:48 2021 +0200

    credit2: make sure we pick a runnable unit from the runq if there is one
    A !runnable unit (temporarily) present in the runq may cause us to
    stop scanning the runq itself too early. Of course, we don't run any
    non-runnable vCPUs, but we end the scan and we fallback to picking
    the idle unit. In other word, this prevent us to find there and pick
    the actual unit that we're meant to start running (which might be
    further ahead in the runq).
    Depending on the vCPU pinning configuration, this may lead to such
    unit to be stuck in the runq for long time, causing malfunctioning
    inside the guest.
    Fix this by checking runnable/non-runnable status up-front, in the runq
    scanning function.
    Reported-by: Michał Leszczyński <michal.leszczynski@xxxxxxx>
    Reported-by: Dion Kant <g.w.kant@xxxxxxxxxx>
    Signed-off-by: Dario Faggioli <dfaggioli@xxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 75f13e9b221e2c8603f15ee1d53318526cf56113
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Jun 4 08:02:14 2021 +0200

    tools/libs/guest: make some definitions private to libxenguest
    There are some definitions which are used in libxenguest only now.
    Move them from libxenctrl over to libxenguest.
    Remove an unused macro.
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 455790573d3bbad6d5a1bb7e9d28b6dd71075693
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Jun 4 08:02:13 2021 +0200

    tools/libs: move xc_core* from libxenctrl to libxenguest
    The functionality in xc_core* should be part of libxenguest instead
    of libxenctrl. Users are already either in libxenguest, or in xl.
    There is one single exception: xc_core_arch_auto_translated_physmap()
    is being used by xc_domain_memory_mapping(), which is used by qemu.
    So leave the xc_core_arch_auto_translated_physmap() functionality in
    This will make it easier to merge common functionality of xc_core*
    and xg_sr_save*.
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit bf1fc18901dfea05a69f661493b934c0db7d3503
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Jun 4 08:02:12 2021 +0200

    tools/libs: move xc_resume.c to libxenguest
    The guest suspend functionality is already part of libxenguest. Move
    the resume functionality from libxenctrl to libxenguest, too.
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit f183854facad996fe891c086c024bca7cbcdc1e4
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Jun 4 08:02:11 2021 +0200

    tools/libs/ctrl: use common p2m mapping code in xc_domain_resume_any()
    Instead of open coding the mapping of the p2m list use the already
    existing xc_core_arch_map_p2m() call, especially as the current code
    does not support guests with the linear p2m map. It should be noted
    that this code is needed for colo/remus only.
    Switching to xc_core_arch_map_p2m() drops the need to bail out for
    bitness of tool stack and guest differing.
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit bd7a29c3d0b937ab542abea06ff1b575abe7247a
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Jun 4 08:02:10 2021 +0200

    tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table
    The core of a pv linux guest produced via "xl dump-core" is nor usable
    as since kernel 4.14 only the linear p2m table is kept if Xen indicates
    it is supporting that. Unfortunately xc_core_arch_map_p2m() is still
    supporting the 3-level p2m tree only.
    Fix that by copying the functionality of map_p2m() from libxenguest to
    Additionally the mapped p2m isn't of a fixed length now, so the
    interface to the mapping functions needs to be adapted. In order not to
    add even more parameters, expand struct domain_info_context and use a
    pointer to that as a parameter.
    Fixes: dc6d60937121 ("libxc: set flag for support of linear p2m list in 
domain builder")
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 7bd8989ab77b6ade3b7a5f4b640a55248d1791a3
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Jun 4 08:02:09 2021 +0200

    tools/libs/guest: fix max_pfn setting in map_p2m()
    When setting the highest pfn used in the guest, don't subtract 1 from
    the value read from the shared_info data. The value read already is
    the correct pfn.
    Fixes: 91e204d37f449 ("libxc: try to find last used pfn when migrating")
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 1a0f2fe2297d122a08fee2b26de5de995fdeca13
Author: George Dunlap <george.dunlap@xxxxxxxxxx>
Date:   Thu May 6 13:38:02 2021 +0100

    SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported
    The support status of 32-bit guests doesn't seem particularly useful.
    With it changed to fully unsupported outside of PV-shim, adjust the PV32
    Kconfig default accordingly.
    Reported-by: Jann Horn <jannh@xxxxxxxxxx>
    Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.