All of lore.kernel.org
 help / color / mirror / Atom feed
From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org
Subject: [xen-unstable-smoke test] 159210: regressions - trouble: blocked/fail
Date: Wed, 10 Feb 2021 15:40:11 +0000	[thread overview]
Message-ID: <osstest-159210-mainreport@xen.org> (raw)

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

Regressions :-(

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

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

version targeted for testing:
 xen                  90b014a6e6ecad036ec5846426afd19b305dedff
baseline version:
 xen                  687121f8a0e7c1ea1c4fa3d056637e5819342f14

Last test of basis   159191  2021-02-09 23:00:29 Z    0 days
Failing since        159206  2021-02-10 12:01:51 Z    0 days    2 attempts
Testing same since   159210  2021-02-10 14:00:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monné <roger.pau@citrix.com>

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 90b014a6e6ecad036ec5846426afd19b305dedff
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Feb 9 15:28:57 2021 +0000

    x86/ucode/amd: Fix microcode payload size for Fam19 processors
    
    The original limit provided wasn't accurate.  Blobs are in fact rather larger.
    
    Fixes: fe36a173d1 ("x86/amd: Initial support for Fam19h processors")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Release-Acked-by: Ian Jackson <iwj@xenproject.org>

commit 0e898ad8bc86d76485ce7a6a29ff2d3fa34d070d
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Feb 9 20:49:07 2021 +0000

    x86/ucode/amd: Handle length sanity check failures more gracefully
    
    Currently, a failure of verify_patch_size() causes an early abort of the
    microcode blob loop, which in turn causes a second go around the main
    container loop, ultimately failing the UCODE_MAGIC check.
    
    First, check for errors after the blob loop.  An error here is unrecoverable,
    so avoid going around the container loop again and printing an
    unhelpful-at-best error concerning bad UCODE_MAGIC.
    
    Second, split the verify_patch_size() check out of the microcode blob header
    check.  In the case that the sanity check fails, we can still use the
    known-to-be-plausible header length to continue walking the container to
    potentially find other applicable microcode blobs.
    
    Before:
      (XEN) microcode: Bad microcode data
      (XEN) microcode: Wrong microcode patch file magic
      (XEN) Parsing microcode blob error -22
    
    After:
      (XEN) microcode: Bad microcode length 0x000015c0 for cpu 0xa000
      (XEN) microcode: Bad microcode length 0x000015c0 for cpu 0xa010
      (XEN) microcode: Bad microcode length 0x000015c0 for cpu 0xa011
      (XEN) microcode: Bad microcode length 0x000015c0 for cpu 0xa200
      (XEN) microcode: Bad microcode length 0x000015c0 for cpu 0xa210
      (XEN) microcode: Bad microcode length 0x000015c0 for cpu 0xa500
      (XEN) microcode: couldn't find any matching ucode in the provided blob!
    
    Fixes: 4de936a38a ("x86/ucode/amd: Rework parsing logic in cpu_request_microcode()")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 1cbc4d89c45cba3929f1c0cb4bca0b000c4f174b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Feb 9 22:10:54 2021 +0000

    x86/ucode/amd: Fix OoB read in cpu_request_microcode()
    
    verify_patch_size() is a maximum size check, and doesn't have a minimum bound.
    
    If the microcode container encodes a blob with a length less than 64 bytes,
    the subsequent calls to microcode_fits()/compare_header() may read off the end
    of the buffer.
    
    Fixes: 4de936a38a ("x86/ucode/amd: Rework parsing logic in cpu_request_microcode()")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 20077d035224c6f3b3eef8b111b8b842635f2c40
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Fri Feb 5 12:53:27 2021 +0100

    tools/configure: add bison as mandatory
    
    Bison is now mandatory when the pvshim build is enabled in order to
    generate the Kconfig.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Release-Acked-by: Ian Jackson <iwj@xenproject.org>
    Reviewed-by: Ian Jackson <iwj@xenproject.org>

commit c9b0242ad44a739e0f4c72b67fd4bcf4b042f800
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Feb 4 10:38:33 2021 +0100

    autoconf: check endian.h include path
    
    Introduce an autoconf macro to check for the include path of certain
    headers that can be different between OSes.
    
    Use such macro to find the correct path for the endian.h header, and
    modify the users of endian.h to use the output of such check.
    
    Suggested-by: Ian Jackson <iwj@xenproject.org>
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Ian Jackson <iwj@xenproject.org>
    Release-Acked-by: Ian Jackson <iwj@xenproject.org>
(qemu changes not included)


                 reply	other threads:[~2021-02-10 15:40 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=osstest-159210-mainreport@xen.org \
    --to=osstest-admin@xenproject.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.