From: xen.org <Ian.Jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [xen-unstable test] 30308: regressions - FAIL
Date: Thu, 18 Sep 2014 11:59:46 +0100 [thread overview]
Message-ID: <osstest-30308-mainreport@xen.org> (raw)
flight 30308 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/30308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 30301
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 guest-saverestore fail REGR. vs. 30301
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 9 guest-start fail never pass
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-armhf-armhf-xl 10 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass
version targeted for testing:
xen f8315ea4f0657dcd7f0bc5bec1328c522b0ceb83
baseline version:
xen 72af6f455ac6afcd46d9a556f90349f2397507e8
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <ian.campbell@citrix.com>
Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
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 pass
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-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-i386-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xl-qemuu-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-amd64-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit f8315ea4f0657dcd7f0bc5bec1328c522b0ceb83
Merge: 5fc4efc 72af6f4
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Wed Sep 17 20:15:28 2014 +0100
Merge branch 'staging' of ssh://xenbits.xen.org/home/xen/git/xen into staging
commit 5fc4efcd3defde429bb048f89decb2ffd96d1c11
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:18 2014 +0100
xl: long output of "list" command now contains Dom0 information
As we've already generated a JSON config for Dom0, print that out when
requested.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit e6afc7063afe06f4609fb2d18fde28f3b54e995e
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:17 2014 +0100
xl: use libxl_retrieve_domain_configuration and JSON format
Before this change, xl stores domain configuration in "xl" format, which
is in fact a verbatim copy of user supplied domain config.
Now libxl provides a new API to retrieve domain configuration, switch to
that new API, store configuration in JSON format.
Tests done so far (xl.{new,old} denotes xl with{,out} "libxl-json"
support):
1. xl.new create then xl.new save, hexdump saved file: domain config
saved in JSON format
2. xl.new create, xl.new save then xl.old restore: failed on
mandatory flag check
3. xl.new create, xl.new save then xl.new restore: succeeded
4. xl.old create, xl.old save then xl.new restore: succeeded
5. xl.new create then local migrate, receiving end xl.new: succeeded
6. xl.old create then local migrate, receiving end xl.new: succeeded
Note that "xl" config is still supported and handled when restarting a
domain. "xl" config file takes precedence over "libxl-json" in that
case, so that user who uses "config-update" to store new config file
won't have regression. All other scenarios (migration, domain listing
etc.) now use the new API.
Lastly, print out warning when users invoke "config-update" to
discourage them from using this command.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 12ebbe2bae28c0e170e76f61ade65b980ae36b55
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:16 2014 +0100
libxl: introduce libxl_userdata_unlink
This will be used in later patch for xl to remove its "xl" userdata
file.
Both CTX lock and userdata lock are taken in this API. CTX lock is taken
to maintain locking hierarchy, but it also has a side effect to protect
against R-M-W by other threads. Userdata lock is used to protect against
domain destruction.
In general application should not rely on these internal locks to
protect its own userdata files. It should deploys its own lock if it
cares.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 9d5550ffc56e72a40c231cead3594403405f2e7e
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:15 2014 +0100
libxl: introduce libxl_retrieve_domain_configuration
Introduce a new public API to return domain configuration. This returned
configuration can be used to rebuild a domain.
Note that this configuration only describes the configuration necessary
to reproduce the guest visible state and does not necessarily include
specific decisions made by the toolstack regarding its current
incarnation (e.g. disk backend) unless they were specified by the
application when the domain was created.
With this approach we can preserve what user has provided in the
original configuration as well as valuable information from xenstore.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 6c0e7d1032363beb308c8ad11ce6c107cf047e26
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:14 2014 +0100
libxl: refactor libxl_get_memory_target
Introduce a helper function which can return both "target" node and
"static-max" node of a domain. Reimplement libxl_get_memory_target using
this helper. libxl__fill_dom0_memory_info is adjusted as well.
This helper will be used in later patch.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 577314768b430107845023d7e489ed0dd53892ad
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:13 2014 +0100
libxl: make libxl_cd_insert "eject" + "insert"
We introduce an intermediate empty state when inserting media into
CDROM. The scheme works like this:
lock json config
write empty state to xenstore
for (;;) {
write user supplied disk to JSON
write disk information to xenstore
}
unlock json config
Bear in mind that all steps can fail. With the proposed scheme, we now
know, if xenstore is empty, then CDROM should be considered empty;
otherwise we should use JSON version of CDROM configuration.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 4197d3abbb3055d3798254eb7ba239bfb5824360
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:12 2014 +0100
libxl: synchronise configuration when we hotplug a device
We update JSON version first, then write to xenstore, so that we
maintain the following invariant: any device which is present in
xenstore has a corresponding entry in JSON.
The workflow is as followed:
lock json config
read json config
update in-memory json config with new entry, replacing
any stale entry
for loop
open xs transaction
check device existence, abort if it exists
write in-memory json config to disk
commit xs transaction
end for loop
unlock json config
Please see comment in libxl_internal.h for correctness proof.
As those routines are called both during domain creation and device
hotplug, we add a flag to indicate whether we need to update JSON
config. This flag is only set to true when we hotplug a device. We
cannot update JSON config during domain creation as JSON config is
committed to disk only when domain creation finishes.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit a788fe0cd8bcb51ef167fc451f837066362d8c82
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Sep 16 11:01:11 2014 +0100
libxl: rework domain userdata file lock
The lock introduced in d2cd9d4f ("libxl: functions to lock / unlock
libxl userdata store") has a bug that can leak the lock file when domain
destruction races with other functions that try to get hold of the lock.
There are several issues:
1. The lock is released too early with libxl__userdata_destroyall
deletes everything in userdata store, including the lock file.
2. The check of domain existence is only done at the beginning of lock
function, by the time the lock is acquired, the domain might have
been gone already.
The effect of this two issues is we can run into such situation:
Process 1 Process 2 domain destruction
# LOCK FUNCTION # LOCK FUNCTION
check domain existence check domain existence
acquire lock (file created)
# LOCK FUNCTION
destroy all files (lock file deleted,
lock released)
acquire lock (file created)
# LOCK FUNCTION destroy domain
# UNLOCK (close fd only)
[ lock file leaked ]
Fix this problem by deploying following changes:
1. Unlink lock file in unlock function.
2. Modify libxl__userdata_destroyall to not delete domain-userdata-lock,
so that the lock remains held until unlock function is called.
3. Check domain still exists when the lock is acquired, unlock if
domain is already gone.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)
reply other threads:[~2014-09-18 10:59 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-30308-mainreport@xen.org \
--to=ian.jackson@eu.citrix.com \
--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).