[Xen-devel] [xen-unstable-smoke test] 138589: regressions - trouble: blocked/fail

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

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a

version targeted for testing:
 xen                  757122c0cf35281618e80cdab37f4f44e5e5ff55
baseline version:
 xen                  85fd4f7a09d8aaa783932b8c15b80ddaff0a174d

Last test of basis   138424  2019-06-24 11:00:52 Z    3 days
Failing since        138482  2019-06-25 15:00:47 Z    1 days   34 attempts
Testing same since   138588  2019-06-27 11:00:54 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Brian Woods <brian.woods@xxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>

jobs:
 build-arm64-xsm                                              fail    
 build-amd64                                                  fail    
 build-armhf                                                  fail    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          blocked 
 test-arm64-arm64-xl-xsm                                      blocked 
 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
    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 757122c0cf35281618e80cdab37f4f44e5e5ff55
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Jun 27 12:34:24 2019 +0200

    AMD/IOMMU: don't "add" IOMMUs
    
    For find_iommu_for_device() to consistently (independent of ACPI tables)
    return NULL for the PCI devices corresponding to IOMMUs, make sure
    IOMMUs don't get mapped to themselves by ivrs_mappings[].
    
    While amd_iommu_add_device() won't be called for IOMMUs from
    pci_add_device(), as IOMMUs have got marked r/o,
    _setup_hwdom_pci_devices() calls there nevertheless. Avoid issuing the
    bogus debugging only "No iommu for ...; cannot be handed to ..." log
    message as well as the non-debugging "setup ... for ... failed (-19)"
    one.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Brian Woods <brian.woods@xxxxxxx>

commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 25 17:34:53 2019 +0200

    drop __get_cpu_var() and __get_cpu_ptr()
    
    this_cpu{,_ptr}() are shorter, and have previously been marked as
    preferred in Xen anyway.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 25 17:34:11 2019 +0200

    x86: replace remaining uses of __get_cpu_var()
    
    this_cpu() is shorter, and when there are multiple uses in a function
    per_cpu() it's also more efficient.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 19b2006a8950eaf11606a6fc3df666f2982321ad
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 25 17:33:40 2019 +0200

    x86/mcheck: replace remaining uses of __get_cpu_var()
    
    this_cpu() is shorter, and when there are multiple uses in a function
    per_cpu() it's also more efficient.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jun 25 17:32:37 2019 +0200

    x86/mcheck: allow varying bank counts per CPU
    
    Up to now we've been assuming that all CPUs would have the same number
    of reporting banks. However, on upcoming AMD CPUs this isn't the case,
    and one can observe
    
    (XEN) mce.c:666: Different bank number on cpu <N>
    
    indicating that Machine Check support would not be enabled on the
    affected CPUs. Convert the count variable to a per-CPU one, and adjust
    code where needed to cope with the values not being the same. In
    particular the mcabanks_alloc() invocations during AP bringup need to
    now allocate maximum-size bitmaps, because the truly needed size can't
    be known until we actually execute on that CPU, yet mcheck_init() gets
    called too early to do any allocations itself.
    
    Take the liberty and also
    - make mca_cap_init() static,
    - replace several __get_cpu_var() uses when a local variable suitable
      for use with per_cpu() appears,
    - correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses,
    - replace a BUG() by panic().
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit b41666f2c17f01c437c870389ab713ee62ae3526
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Tue Jun 25 15:39:44 2019 +0200

    config: don't hardcode toolchain binaries
    
    Currently the names of the build toolchain binaries are hardcoded in
    StdGNU.mk, and the values from the environment are ignored.
    
    Switch StdGNU.mk to use '?=' instead of '=', so that values from the
    environment are used if present, else default to the values provided
    by the config file.
    
    This change fixes the gitlab CI loop, that was relying on passing
    custom values in the environment variables for the compiler and the
    linker.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
(qemu changes not included)

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