|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 127059: regressions - FAIL
flight 127059 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/127059/ 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 1 days Failing since 127042 2018-08-31 12:00:37 Z 0 days 4 attempts Testing same since 127052 2018-08-31 16:00:35 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> 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) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |