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

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

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

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                  61649709421a5a7c1a9fbb45cd8ff15a299bf6ee
baseline version:
 xen                  f04955e18502035121776f6e09d83ae5a36c773c

Last test of basis   126996  2018-08-30 15:01:02 Z    1 days
Testing same since   127042  2018-08-31 12:00:37 Z    0 days    2 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>
  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 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)

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