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

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

flight 155225 xen-unstable-smoke real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt     12 guest-start              fail REGR. vs. 155128

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-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                  de16a8fa0db7f1879442cf9cfe865eb2e9d98e6d
baseline version:
 xen                  c73952831f0fc63a984e0d07dff1d20f8617b81f

Last test of basis   155128  2020-09-30 08:01:25 Z    1 days
Failing since        155144  2020-09-30 16:01:24 Z    0 days    7 attempts
Testing same since   155225  2020-10-01 12:00:28 Z    0 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Anthony PERARD <anthony.perard@xxxxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Paul Durrant <paul@xxxxxxx>
  Paul Durrant <pdurrant@xxxxxxxxxx>
  Wei Liu <wl@xxxxxxx>

 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-amd64                    pass    
 test-amd64-amd64-libvirt                                     fail    

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 de16a8fa0db7f1879442cf9cfe865eb2e9d98e6d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Sep 21 13:17:30 2020 +0100

    x86: Use LOCK ADD instead of MFENCE for smp_mb()
    MFENCE is overly heavyweight for SMP semantics on WB memory, because it also
    orders weaker cached writes, and flushes the WC buffers.
    This technique was used as an optimisation in Java[1], and later adopted by
    Linux[2] where it was measured to have a 60% performance improvement in 
    The stack is used because it is hot in the L1 cache, and a -4 offset is used
    to avoid creating a false data dependency on live data.
    For 64bit userspace, the Red Zone needs to be considered.  Use -32 to allow
    for a reasonable quantity of Red Zone data, but still have a 50% chance of
    hitting the same cache line as %rsp.
    Fix up the 32 bit definitions in HVMLoader and libxc to avoid a false data
    [1] https://shipilev.net/blog/2014/on-the-fence-with-dependencies/
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 707eb41ae2dde4636261f631224c97e9c0b16b56
Author: Paul Durrant <pdurrant@xxxxxxxxxx>
Date:   Tue Sep 15 15:10:07 2020 +0100

    xl: implement documented '--force' option for block-detach
    The manpage for 'xl' documents an option to force a block device to be
    released even if the domain to which it is attached does not co-operate.
    The documentation also states that, if the force flag is not specified, the
    block-detach operation should fail.
    Currently the force option is not implemented and a non-forced block-detach
    will auto-force after a time-out of 10s. This patch implements the force
    option and also stops auto-forcing a non-forced block-detach by calling
    libxl_device_disk_safe_remove() rather than libxl_device_disk_remove(),
    allowing the operation to fail cleanly as per the documented behaviour.
    NOTE: The documentation is also adjusted since the normal positioning of
          options is before compulsory parameters. It is also noted that use of
          the --force option may lead to a guest crash.
    Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 6df07f9fbe1e9b65a40183f79a6171200dc877dd
Author: Paul Durrant <pdurrant@xxxxxxxxxx>
Date:   Tue Sep 15 15:10:06 2020 +0100

    libxl: provide a mechanism to define a device 'safe remove' function...
    ... and use it to define libxl_device_disk_safe_remove().
    This patch builds on the existent macro magic by using a new value of the
    'force' field in in libxl__ao_device.
    It is currently defined as an int but is used in a boolean manner where
    1 means the operation is forced and 0 means it is not (but is actually 
    after a 10s time-out). In adding a third value, this patch re-defines 
    as a struct type (libxl__force) with a single 'flag' field taking an
    enumerated value:
    LIBXL__FORCE_AUTO - corresponding to the old 0 value
    LIBXL__FORCE_ON   - corresponding to the old 1 value
    LIBXL__FORCE_OFF  - the new value
    The LIBXL_DEFINE_DEVICE_REMOVE() macro is then modified to define the
    libxl_device_<type>_remove() and libxl_device_<type>_destroy() functions,
    setting LIBXL__FORCE_AUTO and LIBXL__FORCE_ON (respectively) in the
    libxl__ao_device passed to libxl__initiate_device_generic_remove() and a
    new macro, LIBXL_DEFINE_DEVICE_SAFE_REMOVE(), is defined that sets
    LIBXL__FORCE_OFF instead. This macro is used to define the new
    libxl_device_disk_safe_remove() function.
    Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wl@xxxxxxx>

commit 11852c7bb070a18c3708b4c001772a23e7d4fc27
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Sep 24 16:36:48 2020 +0200

    tools/xenstore: set maximum number of grants needed
    When running as a stubdom Xenstore should set the maximum number of
    grants needed via a call of xengnttab_set_max_grants(), as otherwise
    the number of domains which can be supported will be 128 only (the
    default number of grants supported by Mini-OS).
    We use one grant per domain so the theoretical maximum number is
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit bfcc97c08c2258316d1cd92c23a441d97ad6ff4e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Sep 29 14:48:52 2020 +0100

    tools/cpuid: Plumb nested_virt down into xc_cpuid_apply_policy()
    Nested Virt is the final special case in legacy CPUID handling.  Pass the
    (poorly named) nested_hvm setting down into xc_cpuid_apply_policy() to break
    the semantic dependency on HVM_PARAM_NESTEDHVM.
    No functional change.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 50a5215f30e964a6f16165ab57925ca39f31a849
Author: Olaf Hering <olaf@xxxxxxxxx>
Date:   Thu Sep 24 20:08:43 2020 +0200

    libxc/bitops: increase potential size of bitmaps
    If the bitmap is used to represent domU pages, the amount of memory is
    limited to 8TB due to the 32bit value. Adjust the code to use 64bit
    values as input. All callers already use some form of 64bit as input,
    so no further adjustment is required.
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 27de84d3ae462bd8311c8267c642ec95afdcf47c
Author: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Date:   Wed Sep 23 12:03:23 2020 +0100

    tools: Fix configure of upstream QEMU
    QEMU as recently switch its build system to use meson and the
    ./configure step with meson is more restrictive that the step used to
    be, most installation path wants to be within prefix, otherwise we
    have this error message:
        ERROR: The value of the 'datadir' option is '/usr/share/qemu-xen' which 
must be a subdir of the prefix '/usr/lib/xen'.
    In order to workaround the limitation, we will set prefix to the same
    one as for the rest of Xen installation, and set all the other paths.
    For reference, a thread in qemu-devel:
        "configure with datadir outside of --prefix fails with meson"
    And an issue in meson:
        "artificial limitation of directories (forced to be in prefix)"
    Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
    Tested-by: Paul Durrant <paul@xxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 0d8d289af7a679c028462c4ed5d98586f9ef9648
Author: Olaf Hering <olaf@xxxxxxxxx>
Date:   Wed Sep 23 08:48:40 2020 +0200

    tools/libxc: report malloc errors in writev_exact
    The caller of writev_exact should be notified about malloc errors
    when dealing with partial writes.
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>
(qemu changes not included)



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