[xen-unstable-smoke test] 141357: regressions - trouble: broken/fail/pass

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

flight 141357 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141357/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm         <job status>                 broken
 test-armhf-armhf-xl           7 xen-boot                 fail REGR. vs. 141253

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-xsm       4 host-install(4)          broken pass in 141353

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm     13 migrate-support-check fail in 141353 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 141353 never pass
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  cd93953538aac6026a8012d14a63b320eadd0c98
baseline version:
 xen                  1014f47c7a808e025b8920ab80bfe73a2888b3e5

Last test of basis   141253  2019-09-12 17:00:43 Z    3 days
Failing since        141255  2019-09-12 21:01:22 Z    3 days   24 attempts
Testing same since   141274  2019-09-13 12:01:53 Z    2 days   20 attempts

------------------------------------------------------------
People who touched revisions under test:
  Chao Gao <chao.gao@xxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Stefano Stabellini <sstabellini@xxxxxxxxxx>

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

broken-job test-arm64-arm64-xl-xsm broken
broken-step test-arm64-arm64-xl-xsm host-install(4)

Not pushing.

------------------------------------------------------------
commit cd93953538aac6026a8012d14a63b320eadd0c98
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:31:34 2019 +0200

    microcode: pass a patch pointer to apply_microcode()
    
    apply_microcode()'s always loading the cached ucode patch forces
    a patch to be stored before being loaded. Make apply_microcode()
    accept a patch pointer to remove the limitation so that a patch
    can be stored after a successful loading.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 86f6706e4f4aa898bd6ffe8f1713fd175cc2c7c9
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:31:01 2019 +0200

    microcode/amd: call svm_host_osvw_init() in common code
    
    Introduce a vendor hook, .end_update_percpu, for svm_host_osvw_init().
    The hook function is called on each cpu after loading an update.
    It is a preparation for spliting out apply_microcode() from
    cpu_request_microcode().
    
    Note that svm_host_osvm_init() should be called regardless of the
    result of loading an update.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 41df5999f1f611ccbaedb15f5a4dbd1c1a634173
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:30:12 2019 +0200

    microcode: remove pointless 'cpu' parameter
    
    Some callbacks in microcode_ops or related functions take a cpu
    id parameter. But at current call sites, the cpu id parameter is
    always equal to current cpu id. Some of them even use an assertion
    to guarantee this. Remove this redundent 'cpu' parameter.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 81cc0f3931435374077184665148335fca245849
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:28:44 2019 +0200

    microcode: remove struct ucode_cpu_info
    
    Remove the per-cpu cache field in struct ucode_cpu_info since it has
    been replaced by a global cache. It would leads to only one field
    remaining in ucode_cpu_info. Then, this struct is removed and the
    remaining field (cpu signature) is stored in per-cpu area.
    
    The cpu status notifier is also removed. It was used to free the "mc"
    field to avoid memory leak.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 831f16274942ce70fbb50c438589f82c7d631257
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:28:13 2019 +0200

    microcode: clean up microcode_resume_cpu
    
    Previously, a per-cpu ucode cache is maintained. Then each CPU had one
    per-cpu update cache and there might be multiple versions of microcode.
    Thus microcode_resume_cpu tried best to update microcode by loading
    every update cache until a successful load.
    
    But now the cache struct is simplified a lot and only a single ucode is
    cached. a single invocation of ->apply_microcode() would load the cache
    and make microcode updated.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 9da23943ccd557ddb6c34e96e3bc078a51ad8205
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:27:42 2019 +0200

    microcode: introduce a global cache of ucode patch
    
    to replace the current per-cpu cache 'uci->mc'.
    
    With the assumption that all CPUs in the system have the same signature
    (family, model, stepping and 'pf'), one microcode update matches with
    one cpu should match with others. Having differing microcode revisions
    on cpus would cause system unstable and should be avoided. Hence, caching
    one microcode update is good enough for all cases.
    
    Introduce a global variable, microcode_cache, to store the newest
    matching microcode update. Whenever we get a new valid microcode update,
    its revision id is compared against that of the microcode update to
    determine whether the "microcode_cache" needs to be replaced. And
    this global cache is loaded to cpu in apply_microcode().
    
    All operations on the cache is protected by 'microcode_mutex'.
    
    Note that I deliberately avoid touching the old per-cpu cache ('uci->mc')
    as I am going to remove it completely in the following patches. We copy
    everything to create the new cache blob to avoid reusing some buffers
    previously allocated for the old per-cpu cache. It is not so efficient,
    but it is already corrected by a patch later in this series.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 68f94ef8e57cea82680b7bda2e03caabcba6d0a6
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:26:51 2019 +0200

    microcode/amd: distinguish old and mismatched ucode in microcode_fits()
    
    Sometimes, an ucode with a level lower than or equal to current CPU's
    patch level is useful. For example, to work around a broken bios which
    only loads ucode for BSP, when BSP parses an ucode blob during bootup,
    it is better to save an ucode with lower or equal level for APs
    
    No functional change is made in this patch. But following patch would
    handle "old ucode" and "mismatched ucode" separately.
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 1097aeb27afedd7fd713ea2d22a7f44c6429ccbc
Author: Chao Gao <chao.gao@xxxxxxxxx>
Date:   Fri Sep 13 12:26:16 2019 +0200

    microcode/intel: extend microcode_update_match()
    
    to a more generic function. So that it can be used alone to check
    an update against the CPU signature and current update revision.
    
    Note that enum microcode_match_result will be used in common code
    (aka microcode.c), it has been placed in the common header. And
    constifying the parameter of microcode_sanity_check() such that it
    can be called by microcode_update_match().
    
    Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 78481f525876a6f753866715abaf834f9a4cbc1a
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Fri Sep 13 12:21:47 2019 +0200

    public/xen.h: update the comment explaining 'Wallclock time'
    
    Since commit 0629adfd80e "Actually set a HVM domain's time offset when it
    sets the RTC", the comment in the public header has been misleading, since
    it claims that wallclock time is only updated by control software.
    Moreover, the comments stating that wc_sec and wc_nsec are seconds and
    nanoseconds (respectively) in UTC since the Unix epoch are bogus. Their
    values are adjusted by the domain's time_offset_seconds value, which is
    updated by a guest write to the emulated RTC and hence the wallclock
    timezone is under guest control.
    
    This patch attempts to bring the comment in line with reality whilst
    keeping it reasonably short.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit f59866e2bc190f0838da1988e15722cac13403e5
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Thu Sep 12 15:18:47 2019 +0100

    Update my MAINTAINERS entries
    
    My Citrix email address will expire shortly.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit 2bcddc4da118d528eb1fbf1637f91175ff9969ec
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Fri Sep 13 08:15:05 2019 +0200

    debugtrace: fix Arm build
    
    Add missing #includes.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 6e3e771203781ba6483636a732b2644fd6cab081
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Wed Sep 11 16:31:34 2019 +0100

    xen/arm: setup: Relocate the Device-Tree later on in the boot
    
    At the moment, the Device-Tree is relocated into xenheap while setting
    up the memory subsystem. This is actually not necessary because the
    early mapping is still present and we don't require the virtual address
    to be stable until unflatting the Device-Tree.
    
    So the relocation can safely be moved after the memory subsystem is
    fully setup. This has the nice advantage to make the relocation common
    and let the xenheap allocator decides where to put it.
    
    Lastly, the device-tree is not going to be used for ACPI system. So
    there are no need to relocate it and can just be discarded.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 0a19673affbc9177ea5f758ba245c70dd1a45a90
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Wed Sep 11 16:19:42 2019 +0100

    xen/arm: bootfd: Fix indentation in process_multiboot_node()
    
    One line in process_multiboot_node() is using hard tab rather than soft
    tab. So fix it!
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/osstest-output