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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           7 xen-boot                 fail REGR. vs. 126996

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  342dcb6430d76ebd1ce229a02bad83f8881c9ac9
baseline version:
 xen                  f04955e18502035121776f6e09d83ae5a36c773c

Last test of basis   126996  2018-08-30 15:01:02 Z    2 days
Failing since        127042  2018-08-31 12:00:37 Z    1 days   14 attempts
Testing same since   127052  2018-08-31 16:00:35 Z    1 days   12 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>
  Kevin Tian <kevin.tian@xxxxxxxxx>
  Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 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 342dcb6430d76ebd1ce229a02bad83f8881c9ac9
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Aug 28 16:00:36 2018 +0000

    x86/hvm: Drop hvm_{vmx,svm} shorthands
    
    By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
    domain side of things), the hvm_{vmx,svm} defines can be dropped, and all 
code
    refer to the correctly-named fields.  This means that the data hierachy is 
no
    longer obscured from grep/cscope/tags/etc.
    
    Reformat one comment and switch one bool_t to bool while making changes.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

commit c285742f33d4cc3e106923ee70031cb556c5e39b
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Aug 28 15:59:28 2018 +0000

    x86/svm: Rename arch_svm_struct to svm_vcpu
    
    The suffix and prefix are redundant, and the name is curiously odd.  Rename 
it
    to svm_vcpu to be consistent with all the other similar structures.  In
    addition, rename local arch_svm local variables to svm for further
    consistency.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

commit 5f3d3a880b74a67f283281e493be87871ca4f555
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Aug 28 15:53:06 2018 +0000

    x86/vmx: Rename arch_vmx_struct to vmx_vcpu
    
    The suffix and prefix are redundant, and the name is curiously odd.  Rename 
it
    to vmx_vcpu to be consistent with all the other similar structures.  In
    addition, rename local arch_vmx local variables to vmx for further
    consistency.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    ---
    CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    
    Some of the local pointers are named arch_vmx.  I'm open to renaming them to
    just vmx (like all the other local pointers) if people are happy with the
    additional patch delta.

commit f99b99ed63812494634463c23e8055b75afe3cde
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Aug 28 15:52:34 2018 +0000

    x86/hvm: Rename v->arch.hvm_vcpu to v->arch.hvm
    
    The trailing _vcpu suffix is redundant, but adds to code volume.  Drop it.
    
    Reflow lines as appropriate.  No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

commit 19dc9448099e93e5cbdf430c6c64b8b463debfad
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Aug 28 15:50:41 2018 +0000

    xen/hvm: Rename d->arch.hvm_domain to d->arch.hvm
    
    The trailing _domain suffix is redundant, but adds to code volume.  Drop it.
    
    Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
    where applicable.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

commit 61649709421a5a7c1a9fbb45cd8ff15a299bf6ee
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 19 17:07:50 2018 +0000

    xen/domain: Allocate d->vcpu[] in domain_create()
    
    For ARM, the call to arch_domain_create() needs to have completed before
    domain_max_vcpus() will return the correct upper bound.
    
    For each arch's dom0's, drop the temporary max_vcpus parameter, and 
allocation
    of dom0->vcpu.
    
    With d->max_vcpus now correctly configured before evtchn_init(), the poll 
mask
    can be constructed suitably for the domain, rather than for the worst-case
    setting.
    
    Due to the evtchn_init() fixes, it no longer calls domain_max_vcpus(), and
    ARM's two implementations of vgic_max_vcpus() no longer need work around the
    out-of-order call.
    
    From this point on, d->max_vcpus and d->vcpus[] are valid for any domain 
which
    can be looked up by domid.
    
    The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call attempt 
with
    max != d->max_vcpus, which does match the older semantics (not that it is
    obvious from the code).  The logic to allocate d->vcpu[] is dropped, but at
    this point the hypercall still needs making to allocate each vcpu.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit 1aea974f04806a74592e0b3cf063e4b47a922b9b
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 19 17:28:50 2018 +0000

    xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value
    
    Make dom0_max_vcpus() a common interface, and implement it on ARM by 
splitting
    the existing alloc_dom0_vcpu0() function in half.
    
    As domain_create() doesn't yet set up the vcpu array, the max value is also
    passed into alloc_dom0_vcpu0().  This is temporary for bisectibility and
    removed in the following patch.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

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

    tools: Pass max_vcpus to XEN_DOMCTL_createdomain
    
    XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually 
prevents a
    toolstack from unpausing a domain with no vcpus.
    
    Originally, d->vcpus[] was an embedded array in struct domain, but c/s
    fb442e217 "x86_64: allow more vCPU-s per guest" in Xen 4.0 altered it to 
being
    dynamically allocated.  A side effect of this is that d->vcpu[] is NULL 
until
    XEN_DOMCTL_max_vcpus has completed, but a lot of hypercalls blindly
    dereference it.
    
    Even today, the behaviour of XEN_DOMCTL_max_vcpus is a mandatory singleton
    call which can't change the number of vcpus once a value has been chosen.
    
    In preparation to remote the hypercall, extend xen_domctl_createdomain with
    the a max_vcpus field and arrange for all callers to pass the appropriate
    value.  There is no change in construction behaviour yet, but later patches
    will rearrange the hypervisor internals.
    
    For the python stubs, extend the domain_create keyword list to take a
    max_vcpus parameter, in lieu of deleting the pyxc_domain_max_vcpus function.
    
    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>

commit 580c458699e367bf427967844fa79086b60da675
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 19 16:50:46 2018 +0000

    xen/domain: Call arch_domain_create() as early as possible in 
domain_create()
    
    This is in preparation to set up d->max_cpus and d->vcpu[] in 
domain_create(),
    and allow later parts of domain construction to have access to the values.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 6425f91c72525295a551bf148d9a6b0fa7971097
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 19 16:06:24 2018 +0000

    xen/gnttab: Fold grant_table_{create,set_limits}() into grant_table_init()
    
    Now that the max_{grant,maptrack}_frames are specified from the very 
beginning
    of grant table construction, the various initialisation functions can be
    folded together and simplified as a result.
    
    Leave grant_table_init() as the public interface, which is more consistent
    with other subsystems.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

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

    xen/domctl: Remove XEN_DOMCTL_set_gnttab_limits
    
    Now that XEN_DOMCTL_createdomain handles the grant table limits, remove
    XEN_DOMCTL_set_gnttab_limits (including XSM hooks and libxc wrappers).
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

commit d704c2d6dc82522434bc358b6c19cbe420b3552d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Mar 19 11:19:52 2018 +0000

    xen/gnttab: Pass max_{grant,maptrack}_frames into grant_table_create()
    
    ... rather than setting the limits up after domain_create() has completed.
    
    This removes the common gnttab infrastructure for calculating the number of
    dom0 grant frames (as the common grant table code is not an appropriate 
place
    for it to live), opting instead to require the dom0 construction code to 
pass
    a sane value in via the configuration.
    
    In practice, this now means that there is never a partially constructed 
grant
    table for a reference-able domain.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Julien Grall <julien.grall@xxxxxxx>

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

    tools: Pass grant table limits to XEN_DOMCTL_set_gnttab_limits
    
    XEN_DOMCTL_set_gnttab_limits is a fairly new hypercall, and is strictly
    mandatory.  As it pertains to domain limits, it should be provided at
    createdomain time.
    
    In preparation to remove the hypercall, extend xen_domctl_createdomain with
    the fields and arrange for all callers to pass appropriate details.  There 
is
    no change in construction behaviour yet, but later patches will rearrange 
the
    hypervisor internals, then delete the hypercall.
    
    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>
(qemu changes not included)

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

 


Rackspace

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