[Xen-devel] [xen-unstable-smoke test] 133446: trouble: blocked/broken

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

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                     <job status>                 broken
 build-arm64-xsm                 <job status>                 broken
 build-armhf                     <job status>                 broken
 build-amd64                   4 host-install(4)        broken REGR. vs. 133382
 build-arm64-xsm               4 host-install(4)        broken REGR. vs. 133382
 build-armhf                   4 host-install(4)        broken REGR. vs. 133382

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           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
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1)         blocked n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 xen                  346e7d0f4b2179b9e0b09f4ebc98cbb3aae39a2c
baseline version:
 xen                  e72ecc7615410e5bf1a1c9a4c7772322c16eeb82

Last test of basis   133382  2019-02-22 22:00:38 Z    4 days
Failing since        133430  2019-02-25 23:00:55 Z    1 days    5 attempts
Testing same since   133446  2019-02-26 20:00:42 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Norbert Manthey <nmanthey@xxxxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>

jobs:
 build-arm64-xsm                                              broken  
 build-amd64                                                  broken  
 build-armhf                                                  broken  
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          blocked 
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     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

broken-job build-amd64 broken
broken-job build-arm64-xsm broken
broken-job build-armhf broken
broken-step build-amd64 host-install(4)
broken-step build-arm64-xsm host-install(4)
broken-step build-armhf host-install(4)

Not pushing.

------------------------------------------------------------
commit 346e7d0f4b2179b9e0b09f4ebc98cbb3aae39a2c
Author: Norbert Manthey <nmanthey@xxxxxxxxx>
Date:   Tue Feb 26 16:57:56 2019 +0100

    x86/vioapic: block speculative out-of-bound accesses
    
    When interacting with io apic, a guest can specify values that are used
    as index to structures, and whose values are not compared against
    upper bounds to prevent speculative out-of-bound accesses. This change
    prevents these speculative accesses.
    
    Furthermore, variables are initialized and the compiler is asked to not
    optimized these initializations, as the uninitialized variables might be
    used in a speculative out-of-bound access. Out of the four initialized
    variables, two are potentially problematic, namely ones in the functions
    vioapic_irq_positive_edge and vioapic_get_trigger_mode.
    
    As the two problematic variables are both used in the common function
    gsi_vioapic, the mitigation is implemented there. As the access pattern
    of the currently non-guest-controlled functions might change in the
    future as well, the other variables are initialized as well.
    
    This is part of the speculative hardening effort.
    
    Signed-off-by: Norbert Manthey <nmanthey@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 443d3ab6daee9bf77ec1cb2ea7e252fb0ce616a8
Author: Norbert Manthey <nmanthey@xxxxxxxxx>
Date:   Tue Feb 26 16:57:18 2019 +0100

    evtchn: block speculative out-of-bound accesses
    
    Guests can issue event channel interaction with guest specified data.
    To avoid speculative out-of-bound accesses, we use the nospec macros,
    or the domain_vcpu function. Where appropriate, we use the vcpu_id of
    the seleceted vcpu instead of the parameter that can be influenced by
    the guest, so that only one access needs to be protected.
    
    This is part of the speculative hardening effort.
    
    Signed-off-by: Norbert Manthey <nmanthey@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 43282a5e64da26fad544e0100abf35048cf65b46
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 26 16:56:26 2019 +0100

    x86/shadow: don't use map_domain_page_global() on paths that may not fail
    
    The assumption (according to one comment) and hope (according to
    another) that map_domain_page_global() can't fail are both wrong on
    large enough systems. Do away with the guest_vtable field altogether,
    and establish / tear down the desired mapping as necessary.
    
    The alternatives, discarded as being undesirable, would have been to
    either crash the guest in sh_update_cr3() when the mapping fails, or to
    bubble up an error indicator, which upper layers would have a hard time
    to deal with (other than again by crashing the guest).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit ce98ee3050a824994ce4957faa8f53ecb8c7da9d
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Tue Feb 26 16:55:06 2019 +0100

    viridian: fix the HvFlushVirtualAddress/List hypercall implementation
    
    The current code uses hvm_asid_flush_vcpu() but this is insufficient for
    a guest running in shadow mode, which results in guest crashes early in
    boot if the 'hcall_remote_tlb_flush' is enabled.
    
    This patch, instead of open coding a new flush algorithm, adapts the one
    already used by the HVMOP_flush_tlbs Xen hypercall. The implementation is
    modified to allow TLB flushing a subset of a domain's vCPUs. A callback
    function determines whether or not a vCPU requires flushing. This mechanism
    was chosen because, while it is the case that the currently implemented
    viridian hypercalls specify a vCPU mask, there are newer variants which
    specify a sparse HV_VP_SET and thus use of a callback will avoid needing to
    expose details of this outside of the viridian subsystem if and when those
    newer variants are implemented.
    
    NOTE: Use of the common flush function requires that the hypercalls are
          restartable and so, with this patch applied, viridian_hypercall()
          can now return HVM_HCALL_preempted. This is safe as no modification
          to struct cpu_user_regs is done before the return.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 1c858928009c51178a9c6cac9e42343ee81dfe37
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Feb 18 10:21:06 2019 +0000

    xen/arm: domain_build: Panic message should end with a newline
    
    Since commit 25eb5eec79 "xen: Fix inconsistent callers of panic()" all
    the panic message should end with a newline. Unfortunately, some
    commits pushed afterwards does not follow the rule.
    
    Modify the offending panic messages to avoid more inconsistency.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit cc85de570c7ed91b32f123bef35e4ac2692cbfef
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Feb 18 10:14:36 2019 +0000

    xen/arm: domain_build: Require the property "cpus" when building a domU
    
    The 3rd argument of function dt_property_read_u32() is only valid when
    the call succeeded. So we cannot assume the value will not be modifed
    in case of failure.
    
    The documentation of Dom0less does not give a default value when the
    property "cpus" is not set. So require the property in the configuration.
    
    Coverity-ID: 1476825
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 83ba64c3ebf0e8d3834e3e5b79acb2ceb2cd9bba
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Feb 18 09:42:27 2019 +0000

    xen/arm: psci: Populate arm_smccc_res on PSCI_FEATURES call
    
    Commit 0bc6a68da5 "xen/arm: Replace call_smc with arm_smccc_smc"
    mistakenly forgot to populate arm_smccc_res. So a garbage value was
    used as return value.
    
    Coverity-ID: 1476827
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
(qemu changes not included)

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