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

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

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

Regressions :-(

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

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-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-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

version targeted for testing:
 xen                  63feb88edf98e46fbae1470484e952526ae3fd8f
baseline version:
 xen                  8cc4476eb8176663b4a495c983daf02e885d4cf3

Last test of basis   140952  2019-09-02 16:02:01 Z    1 days
Testing same since   140975  2019-09-03 13:04:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      pass    
 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 63feb88edf98e46fbae1470484e952526ae3fd8f
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Sep 3 14:51:28 2019 +0200

    debugtrace: use common output function
    
    Today dumping the debugtrace buffers is done via sercon_puts(), while
    direct printing of trace entries (after toggling output to the console)
    is using serial_puts().
    
    Use sercon_puts() in both cases, as the difference between both is not
    really making sense.
    
    In order to prepare moving debugtrace functionality to an own source
    file rename sercon_puts() to console_serial_puts() and make it globally
    visible.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 73dad9d966e871abc6b8bae05bd83e1ae3af52ae
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Sep 3 14:50:33 2019 +0200

    x86emul: support INVPCID
    
    Just like for INVLPGA the HVM hook only supports PCID 0 for the time
    being for individual address invalidation. It also translates the other
    types to a full flush, which is architecturally permitted and
    performance-wise presumably not much worse because emulation is slow
    anyway.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 749c6e3c0e733a3f18d9c7d9f903122b620157c3
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Sep 3 14:49:52 2019 +0200

    x86emul: generalize invlpg() hook
    
    The hook is already in use for INVLPGA as well. Rename the hook and add
    parameters. For the moment INVLPGA with a non-zero ASID remains
    unsupported, but the TODO item gets pushed into the actual hook handler.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 4d4fec207b472a7483483b99c3d94537b06cddad
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Sep 3 14:49:20 2019 +0200

    x86/HVM: ignore guest INVD uses
    
    The only place we'd expect the insn to be sensibly used is in
    (virtualization unaware) firmware.
    
    Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit ad3abc47dd23c19c9a66986b58e45172ca3ea1ed
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Sep 3 14:48:19 2019 +0200

    x86emul: support WBNOINVD
    
    Rev 037 of Intel's ISA extensions document does not state intercept
    behavior for the insn (I've been unofficially told that the distinction
    is going to be by exit qualification, as I would have assumed
    considering that this way it's sufficiently transparent to unaware
    software, as using WBINVD in place of WBNOINVD is always correct, just
    less efficient). Similarly AMD's PM volume 2 version 3.31 only states
    that both use the same VMEXIT, but not how to distinugish them (other
    than by decoding the insn). Therefore in the HVM case for now it'll be
    backed by the same ->wbinvd_intercept() handlers.
    
    Use this occasion and also add the two missing table entries for
    CLDEMOTE, which doesn't require any further changes to make work.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit c0536ed315b26e93d62bcbc296764d6a35b13ae1
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Sep 3 14:47:18 2019 +0200

    public: add macro for defining variable length array in public headers
    
    Several public headers of the hypervisor contain structures with
    variable length arrays. In order to be usable with different compilers
    those definitions are depending on the compiler type and the standard
    supported by the compiler.
    
    In order to avoid open coding the different variants in each header
    add a common macro for that purpose in xen.h.
    
    This at once corrects most of the definitions which miss one case
    leading to not defining the array at all.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 4dc12371f3f8f61fb9e9eec8a89d0755880bdd62
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Tue Sep 3 14:46:08 2019 +0200

    x86/domain: remove the 'oos_off' flag
    
    The flag is not needed since the domain 'options' can now be tested
    directly.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
(qemu changes not included)

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