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

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

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

Regressions :-(

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

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-i386  1 build-check(1)         blocked n/a
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  db0eee0a071e2e3e18e79d21a9b1d6724edeeeb3
baseline version:
 xen                  a43cc8fc0827a4110b884b0fd94bf98628f27ab7

Last test of basis    97725  2016-07-20 18:03:39 Z    4 days
Testing same since    99610  2016-07-25 11:02:40 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Sander Eikelenboom <linux@xxxxxxxxxxxxxx>

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 test-armhf-armhf-xl                                          pass    
 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


Not pushing.

------------------------------------------------------------
commit db0eee0a071e2e3e18e79d21a9b1d6724edeeeb3
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Jul 18 22:04:43 2016 +0100

    x86/vMSI-X: Fix host crash when shutting down guests with MSI capable 
devices
    
    c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused MSI-X
    table infrastructure not to always be initialised, but it missed one path
    which needed an is-initialised check.
    
    If a devices is passed through to a domain which is MSI capable but not 
MSI-X
    capable, the call to msixtbl_init() is omitted, but a 
XEN_DOMCTL_unbind_pt_irq
    hypercall still calls into msixtbl_pt_unregister().  This follows the linked
    list pointer which is still NULL.
    
    Introduce an is-initalised check to msixtbl_pt_unregister().
    
    Furthermore, the purpose of the open-coded msixtbl_list.next check is rather
    subtle.  Introduce an msixtbl_initialised() predicate instead, which makes 
its
    purpose far more obvious.
    
    Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Tested-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit d933b37eb404f27557e3e8468482c8ddaeaee60e
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Fri Jul 22 14:04:53 2016 +0200

    xen: credit2: don't let b_avgload go negative.
    
    The ASSERT() made effective by b5b5876619bd8ec2e
    ("xen: credit2: fix two s_time_t handling issues
    in load balancing") triggers for b_avgload (spotted
    by OSSTest).
    
    b_avgload is where we store the prediction of how
    the load of a runqueue will look like in the medium
    to long term, because of a vcpu being added to or
    removed from there.
    
    On vcpu removal, saturate down b_avgload to zero,
    as it makes very few sense to predict that the
    load of a runqueue will at some point become negative!
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit fcaa19dfac9b6050e87cb192217d748d9290de44
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Wed Jul 20 17:10:46 2016 +0100

    xen/arm: p2m: Fix multi-lines coding style comments
    
    The start and end markers should be on separate lines.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 74412ede07a756678f4c3324154a023cdcaf8f52
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Wed Jul 20 17:10:45 2016 +0100

    xen/arm: p2m: Restrict usage of get_page_from_gva to the current vCPU
    
    The function get_page_from_gva translates a guest virtual address to a
    machine address. The translation involves the register VTTBR_EL2,
    TTBR0_EL1, TTBR1_EL1 and SCTLR_EL1.
    
    Currently, only the first register is context switch is the current
    domain is not the same. This will result to use the wrong TTBR*_EL1 and
    SCTLR_EL1 for the translation.
    
    To fix the code properly, we would have to context switch all the
    registers mentioned above when the vCPU in parameter is not the current
    one. Similar things would need to be done in the callee
    p2m_mem_check_and_get_page.
    
    Given that the only caller of this function with the vCPU that may not
    be current is a guest debugging function (show_guest_stack), restrict
    the usage to the current vCPU for the time being.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 7b3d480221e0ff4814675388fe375f21ba87bc26
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Wed Jul 20 17:10:44 2016 +0100

    xen/arm: p2m: Pass the vCPU in parameter to get_page_from_gva
    
    The function get_page_from_gva translates a guest virtual address to a
    machine address. The translation involves the register VTTBR_EL2,
    TTBR0_EL1, TTBR1_EL1 and SCTLR_EL1. Whilst the first register is per
    domain (the p2m is common to every vCPUs), the last 3 are per-vCPU.
    
    Therefore, the function should take the vCPU in parameter and not the
    domain. Fixing the actual code path will be done a separate patch.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit c3cfccdd007a81bc6cfc31851111523880089cbd
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Wed Jul 20 17:10:43 2016 +0100

    xen/arm: system: Use the correct parameter name in local_irq_restore
    
    The parameter to store the flags is called 'x' and not 'flags'.
    Thankfully all the user of the macro is passing 'flags'.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel