[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen-unstable-smoke test] 102713: regressions - trouble: blocked/broken/pass



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   4 host-build-prep          fail REGR. vs. 102693

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  3a782c76036063e9b654fb54e952211ddc1e38f6
baseline version:
 xen                  99a10da1b4fee8ef7a096e5fd3608f6c15932eb0

Last test of basis   102693  2016-11-28 09:01:45 Z    1 days
Testing same since   102713  2016-11-29 16:01:44 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Stefano Stabellini <sstabellini@xxxxxxxxxx>
  Wei Chen <Wei.Chen@xxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  broken  
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     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 3a782c76036063e9b654fb54e952211ddc1e38f6
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Nov 29 16:01:03 2016 +0100

    credit2: make runqueues be per-socket by default
    
    Benchmarks have shown that per-socket runqueues arrangement
    behaves better (e.g., we achieve better load balancing)
    than the current per-core default.
    
    Here's an example (coming from
    https://lists.xen.org/archives/html/xen-devel/2016-06/msg02287.html ):
    
    |=======================================|
    | XEN BUILD TIME, LOW LOAD, NO NOISE    |
    |---------------------------------------|
    |       runq=core   runq=socket         |
    |         35.200       33.433           |
    |---------------------------------------|------------------------------|
    | XEN BUILD TIME, HIGH LOAD, NO NOISE   | IPERF, HIGH LOAD, NO NOISE   |
    |---------------------------------------|------------------------------|
    |       runq=core   runq=socket         |     runq=core runq=socket    |
    |         18.013       18.530           |       23.200     23.466      |
    |---------------------------------------|------------------------------|
    | XEN BUILD TIME, LOW LOAD, WITH NOISE  |
    |-------------------------------------  |
    |       runq=core   runq=socket         |
    |         45.866       39.493           |
    |---------------------------------------|------------------------------|
    | XEN BUILD TIME, HIGH LOAD, WITH NOISE | IPERF, HIGH LOAD, WITH NOISE |
    |---------------------------------------|------------------------------|
    |       runq=core   runq=socket         |     runq=core runq=socket    |
    |         36.840       29.080           |       19.967     21.000      |
    |=======================================|==============================|
    
    The only reason why we went for per-core, initially, was to
    introduce some form of hyperthreading support. Now we have
    hyperthreading support, independently from how runqueues
    are organized (9bb9c7388 "xen: credit2: implement true SMT
    support"), and thus we can switch to per-socket.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit d066b5b9ba8ca60b39127b3c9b1cd62a52307174
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Tue Nov 29 16:00:48 2016 +0100

    libacpi: fix compilation when cross building the tools
    
    The tools (such as mk_dsdt) can be cross-built when it may not be
    desirable to build them on the target.
    
    The commit c4ac1077 "libxl/arm: Generate static ACPI DSDT table"
    introduced support of ARM64 in mk_dsdt but also break cross-building
    tools because the ACPI tables are not correct.
    
    While mk_dsdt should generate ACPI table for the target architecture, it
    currently generates the one for the host. This is because the source
    code contains reference to the host architecture (__aarch64__,
    __x86_64__, __i386__) when it should be the target architecture.
    
    Replace all __aarch64__, __x86_64__, __i386__ by the corresponding
    CONFIG_*.
    
    Also expose the CONFIG_* to the source code as the currently only
    exposed to the Makefile.
    
    Reported-by: Andrii Anisov <andrii.anisov@xxxxxxxxx>
    Suggested-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 6aaff7b407ca76dcfc4fe81f2afe9d1594cb0d6b
Author: Wei Chen <Wei.Chen@xxxxxxx>
Date:   Tue Nov 29 15:59:55 2016 +0100

    arm32: handle async aborts delivered while at HYP
    
    If guest generates an asynchronous abort and then traps into HYP
    (by HVC or IRQ) before the abort has been delivered, the hypervisor
    could not catch it, because the PSTATE.A bit is masked all the time
    in hypervisor. So this asynchronous abort may be slipped to next
    running guest with PSTATE.A bit unmasked.
    
    In order to avoid this, it is necessary to take the abort at HYP, by
    clearing the PSTATE.A bit. In this patch, we unmask the PSTATE.A bit
    to open a window to catch guest-generated asynchronous abort in all
    Guest -> HYP switch paths. If we caught such asynchronous abort in
    checking window, the HYP data abort exception will be triggered and
    the abort source guest will be crashed.
    
    This is part of XSA-201.
    
    Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
    Reviewed-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit f8c6a9334b251d2e78b0873a71b4d369908fb123
Author: Wei Chen <Wei.Chen@xxxxxxx>
Date:   Tue Nov 29 15:59:26 2016 +0100

    arm: crash the guest when it traps on external abort
    
    If we spot a data or prefetch abort bearing the ESR_EL2.EA bit set, we
    know that this is an external abort, and that should crash the guest.
    
    This is part of XSA-201.
    
    Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reviewed-by: Steve Capper <steve.capper@xxxxxxx>
    Reviewed-by: Julien Grall <Julien.Grall@xxxxxxx>

commit 36008800e81bc061cce1fd204a0b638f9dc61c70
Author: Wei Chen <Wei.Chen@xxxxxxx>
Date:   Tue Nov 29 15:58:57 2016 +0100

    arm64: handle async aborts delivered while at EL2
    
    If EL1 generates an asynchronous abort and then traps into EL2
    (by HVC or IRQ) before the abort has been delivered, the hypervisor
    could not catch it, because the PSTATE.A bit is masked all the time
    in hypervisor. So this asynchronous abort may be slipped to next
    running guest with PSTATE.A bit unmasked.
    
    In order to avoid this, it is necessary to take the abort at EL2, by
    clearing the PSTATE.A bit. In this patch, we unmask the PSTATE.A bit
    to open a window to catch guest-generated asynchronous abort in all
    EL1 -> EL2 swich paths. If we catched such asynchronous abort in
    checking window, the hyp_error exception will be triggered and the
    abort source guest will be crashed.
    
    This is part of XSA-201.
    
    Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
    Reviewed-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 2cf7d2bafb9b68add1710b8c3f7ecad58e53a9db
Author: Wei Chen <Wei.Chen@xxxxxxx>
Date:   Tue Nov 29 15:57:52 2016 +0100

    arm64: handle guest-generated EL1 asynchronous abort
    
    In current code, when the hypervisor receives an asynchronous abort
    from a guest, the hypervisor will do panic, the host will be down.
    We have to prevent such security issue, so, in this patch we crash
    the guest, when the hypervisor receives an asynchronous abort from
    the guest.
    
    This is part of XSA-201.
    
    Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reviewed-by: Steve Capper <steve.capper@xxxxxxx>
    Reviewed-by: Julien Grall <Julien.Grall@xxxxxxx>
(qemu changes not included)

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.