From: xen.org <Ian.Jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [xen-unstable test] 29577: regressions - FAIL
Date: Sun, 3 Aug 2014 02:18:46 +0100 [thread overview]
Message-ID: <osstest-29577-mainreport@xen.org> (raw)
flight 29577 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/29577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 11 guest-saverestore.2 fail REGR. vs. 29537
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-amd64-i386-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pcipt-intel 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-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-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 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-qemut-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-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 8b24b07eef3ba13ce48d800f28c1c28de5a2b4a7
baseline version:
xen a1ac4cf52e38386bac7ac3440c7da0099662ca5c
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Dario Faggioli <dario.faggioli@citrix.com>
Don Slutz <dslutz@verizon.com>
Feng Wu <feng.wu@intel.com>
George Dunlap <george.dunlap@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Sander Eikelenboom <linux@eikelenboom.it>
Vitaly Kuznetsov <vkuznets@redhat.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 8b24b07eef3ba13ce48d800f28c1c28de5a2b4a7
Author: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Date: Fri Aug 1 16:48:30 2014 +0200
x86, amd_ucode: safeguard against #GP
When HW tries to load a corrupted patch, it generates #GP
and depending on 'noreboot' parameter on grub, the system
is either stuck in a reboot loop or is hung. Use wrmsr_safe
instead of wrmsrl so that we fail to load microcode gracefully.
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 6784dd6fdc43914e9bf5b080e12c7877d000dffa
Author: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Date: Fri Aug 1 16:47:48 2014 +0200
x86, amd_ucode: fix coverity issues found in cpu_request_microcode()
This patch fixes issues reported by coverity.
- CID 1229147: dead code
- CID 1229148: possible resource leak of mc_amd due to goto out statements.
Coverity-IDs: 1229147, 1229148
Reported-by: Andrew Cooper<andrew.cooper3@citrix.com>
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Reviewed-by: Andrew Cooper<andrew.cooper3@citrix.com>
commit 400b3bd6426f3334e47f16d55fd42f438d7fe6fa
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Fri Aug 1 16:46:40 2014 +0200
evtchn: make EVTCHNOP_reset suitable for kexec
It would be nice to allow guests to close all event channels in
ABI-agnostic way in case of kexec/kdump. EVTCHNOP_reset looks suitable
for this purpose. However control blocks for vcpus and event array need
cleanup when FIFO ABI is being used.
With this change a guest can simply do EVTCHNOP_reset before kexec in
both 2-level and FIFO cases. It is also important to perform store/console
channel remapping after such call.
The issue can also be solved by introducing a new EVTCHNOP operation but
it seems that EVTCHNOP_reset can be reused.
[The idea was suggested by Ian Campbell, Andrew Cooper, and David Vrabel]
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
commit 340f8cb83013dc80ebd29ed5b743040a5a45c146
Author: Feng Wu <feng.wu@intel.com>
Date: Fri Aug 1 16:40:39 2014 +0200
x86/hvm: always do SMAP check when updating secondary system time for guest
In this patch, we always do the SMAP check when updating secondary
system time for the guest when SMAP is enabled by it.
Signed-off-by: Feng Wu <feng.wu@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 31ae587e6f0181bf1f7d196fe1b49357c8922e60
Author: Feng Wu <feng.wu@intel.com>
Date: Fri Aug 1 16:39:17 2014 +0200
x86/hvm: always do SMAP check when updating runstate_guest(v)
In the current implementation, we honor the guest's CPL and AC
to determain whether do the SMAP check or not for runstate_guest(v).
However, this doesn't work. The VMCS feild is invalid when we try
to get geust's SS by hvm_get_segment_register(), since the
right VMCS has not beed loaded for the current VCPU.
In this patch, we always do the SMAP check when updating
runstate_guest(v) for the guest when SMAP is enabled by it.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Feng Wu <feng.wu@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
commit d91b0f9b58219724717db503f46ff2f731aa4c59
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri Aug 1 16:32:39 2014 +0200
x86/cpu: drop the num_siblings check against nr_cpu_ids
The printk() is missing a newline which resulted in console corruption.
However, nr_cpu_ids can be legitimately lower than valid num_sibling values
given certain compile or boot time configuration.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit e9425f05b90811458a08355a55a0b0d608c440cf
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Aug 1 16:29:27 2014 +0200
x86/ACPI: allow CMOS RTC use even when ACPI says there is none
HP is setting the ACPI_FADT_NO_CMOS_RTC flag on newer systems,
regardless of whether they're being booted from UEFI. Add a command
line option to allow probing for a working RTC in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit fb33b2bd7fda7b183a6bf07995c0ff476b676414
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Aug 1 16:28:48 2014 +0200
docs: make .txt files over-writable when building from r/o sources
Otherwise an incremental build will fail to overwrite the destination
files.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 705fad1227a3313f05e0f64da46d19a5c52dacde
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Tue Jul 29 18:07:09 2014 +0200
libxl: automatic NUMA placement affects soft affinity
vCPU soft affinity and NUMA-aware scheduling does not have
to be related. However, soft affinity is how NUMA-aware
scheduling is actually implemented, and therefore, by default,
the results of automatic NUMA placement (at VM creation time)
are also used to set the soft affinity of all the vCPUs of
the domain.
Of course, this only happens if automatic NUMA placement is
enabled and actually takes place (for instance, if the user
does not specify any hard and soft affiniy in the xl config
file).
This also takes care of the vice-versa, i.e., don't trigger
automatic placement if the config file specifies either an
hard (the check for which was already there) or a soft (the
check for which is introduced by this commit) affinity.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 3d00662816fe74678c5b233c59e40dca604ca2bd
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Tue Jul 29 18:06:52 2014 +0200
libxl/xl: make it possible to specify soft-affinity in domain config file
To do so, we add the vcpu_soft_affinity array to build_info, and
treat it much like vcpu_hard_affinity. The new config option is
called "cpus_soft".
Note that the vcpu_hard_affinity array, introduced in a previous
patch, and the vcpu_soft_affinity array, introduced here, share
the same LIBXL_HAVE_xxx macro, in libxl.h. That is called
LIBXL_HAVE_BUILDINFO_VCPU_AFFINITY_ARRAYS, and was introduced
together with vcpu_hard_affinity, but only inside a comment.
In this change, we uncomment, and hence properly define it.
In order to avoid having to issue separate calls to
libxl_set_vcpuaffinity() (one for hard affinity and one for soft
affinity) in libxl__build_pre(), in case the caller uses
b_info->cpumap (for the former) and b_info->vcpu_soft_affinity (for
the latter), we also set (again!) a new default for b_info->cpumap.
This allows, from this change on, to always and only deal with
b_info->vcpu_hard_affinity all around libxl internals.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 14ea07848b8b0f00ea311ee5413932129b6f6c72
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Tue Jul 29 18:06:42 2014 +0200
xl: move the vcpu affinity parsing in a function
so that such parsing code can be used for both hard and soft
affinity, the support for which is introduced in the next
change.
This is pure code motion, no functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit af589e1a9c77c52be5da84c6eabc92a2bb0e72d2
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Tue Jul 29 18:06:28 2014 +0200
xl: move away from the use of cpumap for hard affinity
and start using the vcpu_hard_affinity array instead. This is done
as when, in a subsequent patch ("libxl/xl: make it possible to
specify soft-affinity in domain config file") we will become able
to deal with soft affinity, code can be shared.
This change also enables more advanced VCPU to PCPU (hard, for now)
affinity specification, in case a list is used, like:
cpus = ["3-4", "2-6,^4"]
What it means is that VCPU 0 must be pinned to PCPU 3,4 and VCPU 1
to PCPUs 2,3,5,6 (before this change, cpus=[xx, yy] only supported
single values). Of course, the old (e.g., cpus=[2, 3]) syntax
continues to work.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 7e474ba61c2fa6babf77466bbf4ce873733a9670
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Tue Jul 29 18:06:17 2014 +0200
xl: enable getting and setting soft affinity
Getting happens via `xl vcpu-list', which now looks like this:
# xl vcpu-list -s
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)
Domain-0 0 0 11 -b- 5.4 8-15 / all
Domain-0 0 1 11 -b- 1.0 8-15 / all
Domain-0 0 14 13 -b- 1.4 8-15 / all
Domain-0 0 15 8 -b- 1.6 8-15 / all
vm-test 3 0 4 -b- 2.5 0-12 / 0-7
vm-test 3 1 0 -b- 3.2 0-12 / 0-7
Setting happens by specifying two pCPU masks to the `xl vcpu-pin'
command, the first one will be hard affinity, the second soft
affinity. If only one mask is specified, it is only hard affinity
that is affected. To change only soft affinity, '-' can be used
as the hard affinity mask parameter, and it will be left alone.
xl manual page is updated accordingly.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 9ef51438e5410650c0525274dcfc7e1a503b6833
Author: Don Slutz <dslutz@verizon.com>
Date: Mon Jul 28 12:06:02 2014 -0400
xenbaked.c: Fix return handling for case of mmap failure
mmap() returns MAP_FAILED not NULL.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 8a14ca08f2aa5e52ffd8b42792ae1f3a708339ee
Author: Don Slutz <dslutz@verizon.com>
Date: Mon Jul 28 12:06:01 2014 -0400
libxl_internal.c: Fix return handling for case of mmap failure
mmap() returns MAP_FAILED not NULL.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 822b956ef7d5ccab86133d0cc8d49d87103adf3e
Author: Don Slutz <dslutz@verizon.com>
Date: Mon Jul 28 12:06:00 2014 -0400
loadpolicy.c: Fix return handling for case of mmap failure
mmap() returns MAP_FAILED not NULL.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)
reply other threads:[~2014-08-03 1:18 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-29577-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).