[Xen-devel] [xen-unstable-smoke test] 144328: regressions - FAIL

[Xen-devel] [xen-unstable-smoke test] 144328: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl         16 guest-start/debian.repeat fail REGR. vs. 144322

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 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                  9a400d1797ec7f77ffefeb5c4e17a8c2e8b91a12
baseline version:
 xen                  34c11725483beb45499f934c7e06e00b55f04ef4

Last test of basis   144322  2019-11-27 11:01:00 Z    0 days
Testing same since   144328  2019-11-27 14:00:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Igor Druzhinin <igor.druzhinin@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien@xen.org>
  Sergey Dyasli <sergey.dyasli@citrix.com>

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                                      pass    
 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


Not pushing.

------------------------------------------------------------
commit 9a400d1797ec7f77ffefeb5c4e17a8c2e8b91a12
Author: Julien Grall <julien@xen.org>
Date:   Tue Nov 26 13:30:23 2019 +0000

    MAINTAINERS: Update path to the livepatch documentation
    
    Commit d661611d08 "docs/markdown: Switch to using pandoc, and fix
    underscore escaping" converted the livepatch documentation from markdown
    to pandoc.
    
    Update MAINTAINERS to reflect the change so the correct maintainers are
    CCed to the patches.
    
    Fixes: d661611d08 ("docs/markdown: Switch to using pandoc, and fix underscore escaping")
    Signed-off-by: Julien Grall <julien@xen.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Release-acked-by: Juergen Gross <jgross@suse.com>

commit 72580a8d3c7ac70859437b69570de67dab668d9f
Author: Sergey Dyasli <sergey.dyasli@citrix.com>
Date:   Wed Nov 27 10:04:30 2019 +0000

    x86/microcode: refuse to load the same revision ucode
    
    Currently if a user tries to live-load the same or older ucode revision
    than CPU already has, he will get a single message in Xen log like:
    
        (XEN) 128 cores are to update their microcode
    
    No actual ucode loading will happen and this situation can be quite
    confusing. Fix this by starting ucode update only when the provided
    ucode revision is higher than the currently cached one (if any).
    This is based on the property that if microcode_cache exists, all CPUs
    in the system should have at least that ucode revision.
    
    Additionally, print a user friendly message if no matching or newer
    ucode can be found in the provided blob. This also requires ignoring
    -ENODATA in AMD-side code, otherwise the message given to the user is:
    
        (XEN) Parsing microcode blob error -61
    
    Which actually means that a ucode blob was parsed fine, but no matching
    ucode was found.
    
    Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
    Reviewed-by: Chao Gao <chao.gao@intel.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Release-acked-by: Juergen Gross <jgross@suse.com>

commit 195b79a97e6721ba8830036f47d2454545f32e44
Author: Igor Druzhinin <igor.druzhinin@citrix.com>
Date:   Tue Nov 26 17:08:19 2019 +0000

    AMD/IOMMU: honour IR setting while pre-filling DTEs
    
    IV bit shouldn't be set in DTE if interrupt remapping is not
    enabled. It's a regression in behavior of "iommu=no-intremap"
    option which otherwise would keep interrupt requests untranslated
    for all of the devices in the system regardless of wether it's
    described as valid in IVRS or not.
    
    Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Release-acked-by: Juergen Gross <jgross@suse.com>
(qemu changes not included)

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