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

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

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

Regressions :-(

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

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

version targeted for testing:
 xen                  4cdb6bfde2300c75725b3e267469bd6c9eeee55e
baseline version:
 xen                  3dd454c6c694409aaedd4ed075d6aeace2dd8391

Last test of basis   125923  2018-08-15 16:00:41 Z    0 days
Testing same since   125928  2018-08-15 19:00:49 Z    0 days    5 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Christian Lindig <christian.lindig@xxxxxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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 4cdb6bfde2300c75725b3e267469bd6c9eeee55e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Mar 16 18:27:24 2018 +0000

    xen/evtchn: Pass max_evtchn_port into evtchn_init()
    
    ... rather than setting it up once domain_create() has completed.  This
    involves constructing a default value for dom0.
    
    No practical change in functionality.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit 4a83497635056d33fe20ef705f35617b1003a276
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Feb 27 17:39:37 2018 +0000

    xen/domctl: Merge set_max_evtchn into createdomain
    
    set_max_evtchn is somewhat weird.  It was introduced with the event_fifo 
work,
    but has never been used.  Still, it is a bounding on resources consumed by 
the
    event channel infrastructure, and should be part of createdomain, rather 
than
    editable after the fact.
    
    Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
    wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

commit 54ed251dc7b85565820019102e533afcea814e16
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Mar 9 14:38:35 2018 +0000

    tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
    
    In future patches, the structure will be extended with further information,
    and this is far cleaner than adding extra parameters.
    
    The python stubs are the only user which passes NULL for the existing config
    option (which is actually the arch substructure).  Therefore, the #ifdefary
    moves to compensate.
    
    For libxl, pass the full config object down into
    libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
    specific settings in the common part of the structure (flags s3_integrity 
and
    oos_off specifically).
    
    No practical change in behaviour.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit acc2a06c780e9e7ffa6373854735503b7d63a1d0
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 12 10:40:33 2018 +0000

    tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
    
    The underlying C function is about to make the same change, and the 
structure
    is going to gain extra fields.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
(qemu changes not included)

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