From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org
Subject: [xen-unstable-smoke test] 125741: trouble: blocked/broken/pass
Date: Thu, 02 Aug 2018 12:34:48 +0000 [thread overview]
Message-ID: <osstest-125741-mainreport@xen.org> (raw)
flight 125741 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125741/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm <job status> broken
build-arm64-xsm 4 host-install(4) broken REGR. vs. 125729
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen 4c9a6546e4c33ba2b170d5c1d0c340c1dd384ffc
baseline version:
xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83
Last test of basis 125729 2018-08-01 11:00:39 Z 1 days
Testing same since 125741 2018-08-02 10:01:09 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Kevin Tian <kevin.tian@intel.com>
jobs:
build-arm64-xsm broken
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm 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
broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)
Not pushing.
------------------------------------------------------------
commit 4c9a6546e4c33ba2b170d5c1d0c340c1dd384ffc
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Jan 24 16:59:42 2018 +0000
xen: Remove domain_crash_synchronous() completely
domain_crash_synchronous() is unsafe to use in general as it may leave
spinlocks held, temporary memory allocated, etc.
With domain_crash_synchronous() removed from the ARM code in 4.11, take the
opportunity to remove the infrastructure completely by opencoding the softirq
loop in the remaining callsites, all of which are destined for deletion.
None of these sites are at risk of having a pending ioreq to qemu, which means
that the vcpu_end_shutdown_deferral() isn't necessary.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit 499a76634d74f4ec663629fe85239e05d0352bb9
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Feb 6 12:01:08 2018 +0000
x86/vmx: Avoid using domain_crash_syncrhonous() in vmx_vmentry_failure()
There is no need for the syncrhonous varient, as the vmentry failure path can
just return to processing softirqs.
This is in aid of trying to remove domain_crash_syncrhonous() from the
codebase.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 48dbb2dbe9d9f92a2890a15bb48a0598c065b9f8
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Aug 1 12:47:50 2018 +0100
x86/vmx: Avoid hitting BUG_ON() after EPTP-related domain_crash()
If the EPTP pointer can't be located in the altp2m list, the domain
is (legitimately) crashed.
Under those circumstances, execution will continue and guarentee to hit the
BUG_ON(idx >= MAX_ALTP2M) (unfortunately, just out of context).
Return from vmx_vmexit_handler() after the domain_crash(), which also has the
side effect of reentering the scheduler more promptly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
reply other threads:[~2018-08-02 12:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-125741-mainreport@xen.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).