|
[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] http://logs.test-lab.xenproject.org/osstest/logs/155225/ 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> 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-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 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 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 VirtIO benchmarks. 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 dependency. [1] https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ [2] https://git.kernel.org/torvalds/c/450cbdd0125cfa5d7bbf9e2a6b6961cc48d29730 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 forced after a 10s time-out). In adding a third value, this patch re-defines 'force' 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 DOMID_FIRST_RESERVED. 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" https://lore.kernel.org/qemu-devel/20200918133012.GH2024@xxxxxxxxxxxxxxxxxxxxxxx/t/ And an issue in meson: "artificial limitation of directories (forced to be in prefix)" https://github.com/mesonbuild/meson/issues/2561 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 |