flight 21989 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/21989/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 2 host-install(2) broken in 21984 REGR. vs. 21888
build-armhf 3 capture-logs !broken in 21984 [st=!broken!]
build-armhf-pvops 2 host-install(2) broken in 21984 REGR. vs. 21888
build-armhf-pvops 3 capture-logs !broken in 21984 [st=!broken!]
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail pass in 21984
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-armhf-armhf-xl 5 xen-boot fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-armhf-armhf-xl 1 xen-build-check(1) blocked in 21984 n/a
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail in 21984 never pass
version targeted for testing:
xen 2df9704ad1bb7484efded4fec9e81f13fab4e839
baseline version:
xen be2f2316f11d56555a37873d3f53bb3f46dec856
------------------------------------------------------------
People who touched revisions under test:
Dario Faggioli <dario.faggioli@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Kouya Shimura <kouya@jp.fujitsu.com>
Nathan Studer <nate.studer@dornerworks.com>
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Tim Deegan <tim@xen.org>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl fail
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-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-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-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-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.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 2df9704ad1bb7484efded4fec9e81f13fab4e839
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:29:57 2013 +0100
x86: eliminate has_arch_mmios()
... as being generally insufficient: Either has_arch_pdevs() or
cache_flush_permitted() should be used (in particular, it is
insufficient to consider MMIO ranges alone - I/O port ranges have the
same requirements if available to a guest).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 79233938ab2a8f273fd5dcdbf8e8381b9eb3a461
master date: 2013-11-12 16:28:47 +0100
commit ec6f0183517615823641785233eeaf8372f674ac
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:28:37 2013 +0100
VMX: don''t crash processing ''d'' debug key
There''s a window during scheduling where "current" and
the active VMCS
may disagree: The former gets set much earlier than the latter. Since
both vmx_vmcs_enter() and vmx_vmcs_exit() immediately return when the
subject vCPU is "current", accessing VMCS fields would, depending
on
whether there is any currently active VMCS, either read wrong data, or
cause a crash.
Going forward we might want to consider reducing the window during
which vmx_vmcs_enter() might fail (e.g. doing a plain __vmptrld() when
v->arch.hvm_vmx.vmcs != this_cpu(current_vmcs) but
arch_vmx->active_cpu
== -1), but that would add complexities (acquiring and - more
importantly - properly dropping v->arch.hvm_vmx.vmcs_lock) that
don''t
look worthwhile adding right now.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 58929248461ecadce13e92eb5a5d9ef718a7c88e
master date: 2013-11-12 11:52:19 +0100
commit 9aa5c832e967ae333caef477521d055c1c49c31e
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:28:05 2013 +0100
nested SVM: adjust guest handling of structure mappings
For one, nestedsvm_vmcb_map() error checking must not consist of using
assertions: Global (permanent) mappings can fail, and hence failure
needs to be dealt with properly. And non-global (transient) mappings
can''t fail anyway.
And then the I/O port access bitmap handling was broken: It checked
only to first of the accessed ports rather than each of them.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Christoph Egger <chegger@amazon.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: b1e87805bf37b446dade93a7eb922bb7d1269756
master date: 2013-11-12 11:51:15 +0100
commit b54a623efbcf5bff25c55117add1b4427b4e2f1b
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri Nov 15 11:27:24 2013 +0100
numa-sched: leave node-affinity alone if not in "auto" mode
If the domain''s NUMA node-affinity is being specified by the
user/toolstack (instead of being automatically computed by Xen),
we really should stick to that. This means domain_update_node_affinity()
is wrong when it filters out some stuff from there even in "!auto"
mode.
This commit fixes that. Of course, this does not mean node-affinity
is always honoured (e.g., a vcpu won''t run on a pcpu of a different
cpupool) but the necessary logic for taking into account all the
possible situations lives in the scheduler code, where it belongs.
What could happen without this change is that, under certain
circumstances, the node-affinity of a domain may change when the
user modifies the vcpu-affinity of the domain''s vcpus. This, even
if probably not a real bug, is at least something the user does
not expect, so let''s avoid it.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 67348c3ac700b8bc9147638c719c3035c5ef20f5
master date: 2013-11-12 10:54:28 +0100
commit e1c1672e9be7886dd50ddd8605855783d7d25e9b
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:26:30 2013 +0100
x86/EFI: make trampoline allocation more flexible
Certain UEFI implementations reserve all memory below 1Mb at boot time,
making it impossible to properly allocate the chunk necessary for the
trampoline. Fall back to simply grabbing a chunk from EfiBootServices*
regions immediately prior to calling ExitBootServices().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
master date: 2013-11-08 11:08:32 +0100
commit cd766e12d4c914f3928537acb64595f5044d43bf
Author: Kouya Shimura <kouya@jp.fujitsu.com>
Date: Fri Nov 15 11:25:46 2013 +0100
x86/hvm: fix restart of RTC periodic timer with vpt_align=1
The commit 58afa7ef "x86/hvm: Run the RTC periodic timer on a
consistent time series" aligns the RTC periodic timer to the
VM''s boot time.
However, it''s aligned later again to the system time in
create_periodic_time()
with vpt_align=1. The next tick might be skipped.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 48535f5798e3e237d9920a74c1ce3802958136c0
master date: 2013-11-08 11:07:14 +0100
commit 406323bdf652767fa2168e5ea4dfaf619d67867b
Author: Nathan Studer <nate.studer@dornerworks.com>
Date: Fri Nov 15 11:25:05 2013 +0100
call sched_destroy_domain before cpupool_rm_domain
The domain destruction code, removes a domain from its cpupool
before attempting to destroy its scheduler information. Since
the scheduler framework uses the domain''s cpupool information
to decide on which scheduler ops to use, this results in the
the wrong scheduler''s destroy domain function being called
when the cpupool scheduler and the initial scheduler are
different.
Correct this by destroying the domain''s scheduling information
before removing it from the pool.
Signed-off-by: Nathan Studer <nate.studer@dornerworks.com>
Reviewed-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 117f67350fd18b11ab09d628b4edea3364b09441
master date: 2013-11-06 10:21:09 +0100
commit c179b2fd803b8b6cc29046088a90791a65d9cb32
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:24:16 2013 +0100
x86/HVM: 32-bit IN result must be zero-extended to 64 bits
Just like for all other operations with 32-bit operand size.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
x86/HVM: 32-bit IN result must be zero-extended to 64 bits (part 2)
Just spotted a counterpart of what commit 9d89100b (same title) dealt
with.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 9d89100ba8b7b02adb7c2e89ef7c81e734942e7c
master date: 2013-11-05 14:51:53 +0100
master commit: 1e521eddeb51a9f1bf0e4dd1d17efc873eafae41
master date: 2013-11-15 11:01:49 +0100
commit ff8c797392bddc04a35463958bfc2d981734d345
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:23:04 2013 +0100
x86: make sure memory block is RAM before passing to the allocator
Memory blocks outside of the always visible 1:1 mapping range get
passed to the allocator separately (once enough other setup was done).
Skipping non-RAM regions, however, was forgotten in adc5afbf ("x86:
support up to 16Tb").
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 227258983401b7e6091967ffaf22ad83f4ebaf6f
master date: 2013-11-04 14:29:24 +0100
commit 53b20077f9f15cd78bad42bfdd98e27c7fe32d5e
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:22:24 2013 +0100
x86/ACPI/x2APIC: guard against out of range ACPI or APIC IDs
Other than for the legacy APIC, the x2APIC MADT entries have valid
ranges possibly extending beyond what our internal arrays can handle,
and hence we need to guard ourselves against corrupting memory here.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Keir Fraser <keir@xen.org>
master commit: 2c24cdcce3269f3286790c63821951a1de93c66a
master date: 2013-11-04 10:10:04 +0100
commit 5c1dcf7d2c03fc9f256313cf99bfd81bddcc967d
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:20:55 2013 +0100
x86: refine address validity checks before accessing page tables
In commit 40d66baa ("x86: correct LDT checks") and d06a0d71
("x86: add
address validity check to guest_map_l1e()") I didn''t really
pay
attention to the fact that these checks would better be done before the
paging_mode_translate() ones, as there''s also no equivalent check
down
the shadow code paths involved here (at least not up to the first use
of the address), and such generic checks shouldn''t really be done
by
particular backend functions anyway.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 343cad8c70585c4dba8afc75e1ec1b7610605ab2
master date: 2013-10-28 12:00:36 +0100
commit 92503639bd8bedd7f9097629f77e2de5a31659b2
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 15 11:20:04 2013 +0100
x86/xsave: also save/restore XCR0 across suspend (ACPI S3)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: e47a90e6dca491c0ceea6ffa18055e7e32565e8e
master date: 2013-10-21 17:26:16 +0200
(qemu changes not included)