[xen-unstable-smoke test] 125950: regressions - FAIL

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

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

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                  70d8543950ad045fddcb78ae11302e713ef09c76
baseline version:
 xen                  3dd454c6c694409aaedd4ed075d6aeace2dd8391

Last test of basis   125923  2018-08-15 16:00:41 Z    0 days
Failing since        125928  2018-08-15 19:00:49 Z    0 days    8 attempts
Testing same since   125950  2018-08-16 09:00:31 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Christian Lindig <christian.lindig@xxxxxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>
  Zhenzhong Duan <zhenzhong.duan@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 70d8543950ad045fddcb78ae11302e713ef09c76
Author: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx>
Date:   Thu Aug 16 09:31:57 2018 +0200

    x86/mmcfg: remove redundant code in pci_mmcfg_reject_broken()
    
    No functional change.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit a9e9837f54973ac45488c24e93ed34cbf20e4c66
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Aug 16 09:30:59 2018 +0200

    gnttab/ARM: properly implement gnttab_create_status_page()
    
    Prevent the "BUG_ON(page_get_owner(pg) != d)" in
    gnttab_unpopulate_status_frames() from triggering.
    
    Reported-by: 王磊 <lei19.wang@xxxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 7626edeaca972e3e823535dcc44338f6b2f0b21f
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Thu Aug 16 09:27:30 2018 +0200

    x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
    
    When emulating a rep I/O operation it is possible that the ioreq will
    describe a single operation that spans multiple GFNs. This is fine as long
    as all those GFNs fall within an MMIO region covered by a single device
    model, but unfortunately the higher levels of the emulation code do not
    guarantee that. This is something that should almost certainly be fixed,
    but in the meantime this patch makes sure that MMIO is truncated at GFN
    boundaries and hence the appropriate device model is re-evaluated for each
    target GFN.
    
    NOTE: This patch does not deal with the case of a single MMIO operation
          spanning a GFN boundary. That is more complex to deal with and is
          deferred to a subsequent patch.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    
    Convert calculations to be 32-bit only.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

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)

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