From: Platform Team regression test user <citrix-osstest@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [xen-unstable baseline-only test] 44407: regressions - trouble: blocked/broken/fail/pass
Date: Thu, 12 May 2016 11:29:10 +0100 [thread overview]
Message-ID: <osstest-44407-mainreport@xen.org> (raw)
This run is configured for baseline tests only.
flight 44407 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 capture-logs !broken [st=!broken!]
build-armhf-pvops 4 capture-logs !broken [st=!broken!]
build-armhf 4 capture-logs !broken [st=!broken!]
build-armhf-xsm 3 host-install(3) broken REGR. vs. 44400
build-armhf-pvops 3 host-install(3) broken REGR. vs. 44400
build-armhf 3 host-install(3) broken REGR. vs. 44400
test-amd64-i386-migrupgrade 20 guest-start/debian fail REGR. vs. 44400
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-build fail like 44400
build-i386-rumpuserxen 6 xen-build fail like 44400
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 44400
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44400
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a
build-armhf-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a
test-armhf-armhf-xl-midway 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a
test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
version targeted for testing:
xen c79fc6c4bee28b40948838a760b4aaadf6b5cd47
baseline version:
xen 4084fee7a3204bf8ccf7d993dea09186e4e7dd48
Last test of basis 44400 2016-05-10 08:19:39 Z 2 days
Testing same since 44407 2016-05-12 02:20:16 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Dario Faggioli <dario.faggioli@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Ross Lagerwall <ross.lagerwall@citrix.com>
Tim Deegan <tim@xen.org>
jobs:
build-amd64-xsm pass
build-armhf-xsm broken
build-i386-xsm pass
build-amd64 pass
build-armhf broken
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt blocked
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops broken
build-i386-pvops pass
build-amd64-rumpuserxen fail
build-i386-rumpuserxen fail
test-amd64-amd64-xl pass
test-armhf-armhf-xl blocked
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm blocked
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumpuserxen-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 blocked
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 blocked
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt pass
test-armhf-armhf-xl-midway blocked
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade fail
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu blocked
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 blocked
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw blocked
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds blocked
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd blocked
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
broken build-armhf-xsm capture-logs !broken
broken-step build-armhf-xsm host-install(3)
broken-step build-armhf-pvops host-install(3)
broken build-armhf-pvops capture-logs !broken
broken-step build-armhf host-install(3)
broken build-armhf capture-logs !broken
Push not applicable.
------------------------------------------------------------
commit c79fc6c4bee28b40948838a760b4aaadf6b5cd47
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue May 10 19:14:34 2016 +0100
QEMU_TAG update
commit c1b368ee2e00741a118fe4f972fbb5347db067ba
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue May 10 18:56:53 2016 +0100
QEMU_TAG update
commit fec659aa2dd9cfc9f35f05266179bbdde75203f0
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Tue May 10 10:10:02 2016 +0100
xsplice: Prevent new symbols duplicating core symbols
When loading patches, the code prevents loading a patch containing a new
symbol that duplicates a symbol from another loaded patch. However, the
check should also prevent loading a new symbol that duplicates a symbol
from the core hypervisor.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 31d961f38bcb0a8fe899bc46a3ef7d05fb381c2b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon May 9 13:13:57 2016 +0000
x86/hvm: Fix invalidation for emulated invlpg instructions
hap_invlpg() is reachable from the instruction emulator, which means
introspection and tests using hvm_fep can end up here. As such, crashing the
domain is not an appropriate action to take.
Fixing this involves rearranging the callgraph.
paging_invlpg() is now the central entry point. It first checks for the
non-canonical NOP case, and calls ino the paging subsystem. If a real flush
is needed, it will call the appropriate handler for the vcpu. This allows the
PV callsites of paging_invlpg() to be simplified.
The sole user of hvm_funcs.invlpg_intercept() is altered to use
paging_invlpg() instead, allowing the .invlpg_intercept() hook to be removed.
For both VMX and SVM, the existing $VENDOR_invlpg_intercept() is split in
half. $VENDOR_invlpg_intercept() stays as the intercept handler only (which
just calls paging_invlpg()), and new $VENDOR_invlpg() functions do the
ASID/VPID management. These later functions are made available in hvm_funcs
for paging_invlpg() to use.
As a result, correct ASID/VPID management occurs for the hvmemul path, even if
it did not originate from an real hardware intercept.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit eee511dec9d1f7e2bdfb4aebfe5ffbd70cdf6f51
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon May 9 18:09:38 2016 +0100
x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()
paging_invlpg() already returns a boolean indicating whether an invalidation
is necessary or not. A return value of 0 indicates that the specified virtual
address wasn't shadowed (or has already been flushed), cannot currently be
cached in the TLB.
This is a performance optimisation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit a373db28eaa1e9011db00cc6359b8ee1112c80e0
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri Apr 22 09:44:53 2016 +0100
x86/hvm: Correct the emulated interaction of invlpg with segments
The `invlpg` instruction is documented to take a memory address, and is not
documented to suffer faults from segmentation violations. It is also
explicitly documented to be a NOP when issued on a non-canonical address.
Experimentally, and subsequently confirmed by both Intel and AMD, the
instruction does take into account segment bases, but will happily invalidate
a TLB entry for a mapping beyond the segment limit.
The emulation logic will currently raise #GP/#SS faults for segment limit
violations, or non-canonical addresses, which doesn't match hardware's
behaviour. Instead, squash exceptions generated by
hvmemul_virtual_to_linear() and proceed with invalidation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit a94b35ddedf5c7327c6b2d9205d0a2aef2e4cfed
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sat May 7 13:41:05 2016 +0100
x86/hvm: Raise #SS faults for %ss-based segmentation violations
Raising #GP under such circumstances is architecturally wrong.
Refer to the Intel or AMD manuals describing faults, and the conditions
under which #SS is raised.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 60935158cbf74f4cd6f69190ced9be0391cfa506
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed May 4 14:52:24 2016 +0100
x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr()
Some callers need the linear address (with appropriate segment base), whether
or not the limit or canonical check succeeds.
While modifying the function, change the return type to bool_t to match its
semantics.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit fdb9a18698c9ab8e8e8e875f20184b4aa5d62825
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue May 10 14:37:00 2016 +0100
sched/rt: Fix memory leak in rt_init()
c/s 2656bc7b0 "xen: adopt .deinit_pdata and improve timer handling"
introduced a error path into rt_init() which leaked prv if the
allocation of prv->repl_timer failed.
Introduce an error cleanup path.
Spotted by Coverity.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Meng Xu <mengxu@cis.upenn.edu>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
---
CC: George Dunlap <george.dunlap@eu.citrix.com>
CC: Dario Faggioli <dario.faggioli@citrix.com>
commit 2656bc7b0c145932e1af80d54d48975edd081997
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Mon May 9 15:41:00 2016 +0100
xen: adopt .deinit_pdata and improve timer handling
The scheduling hooks API is now used properly, and no
initialization or de-initialization happen in
alloc/free_pdata any longer.
In fact, just like it is for Credit2, there is no real
need for implementing alloc_pdata and free_pdata.
This also made it possible to improve the replenishment
timer handling logic, such that now the timer is always
kept on one of the pCPU of the scheduler it's servicing.
Before this commit, in fact, even if the pCPU where the
timer happened to be initialized at creation time was
moved to another cpupool, the timer stayed there,
potentially inferfering with the new scheduler of the
pCPU itself.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-and-Tested-by: Meng Xu <mengxu@cis.upenn.edu>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit fb0c3a8a30906005afc8c976b5c469d86496871e
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Tue Apr 26 18:56:56 2016 +0200
xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()
interrupts are already disabled when calling the hook
(from schedule_cpu_switch()), so we must use spin_lock()
and spin_unlock().
Add an ASSERT(), so we will notice if this code and its
caller get out of sync with respect to disabling interrupts
(and add one at the same exact occurrence of this pattern
in Credit1 too)
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
reply other threads:[~2016-05-12 10:29 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-44407-mainreport@xen.org \
--to=citrix-osstest@xenproject.org \
--cc=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xensource.com \
/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).