flight 13920 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13920/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pv 9 guest-start fail REGR. vs. 13912
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
version targeted for testing:
xen a69c8e5c4afc
baseline version:
xen ca3e8190a72c
------------------------------------------------------------
People who touched revisions under test:
Ben Guthro <ben@guthro.net>
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
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-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv fail
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-i386-i386-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-i386-i386-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.
------------------------------------------------------------
changeset: 25871:a69c8e5c4afc
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 04 10:16:20 2012 +0200
x86/ucode: fix Intel case of resume handling on boot CPU
Checking the stored version doesn''t tell us anything about the need
to
apply the update (during resume, what is stored doesn''t necessarily
match what is loaded).
Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.
Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ben Guthro <ben@guthro.net>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25965:4496d56c68a0
xen-unstable date: Fri Sep 28 07:28:11 UTC 2012
changeset: 25870:648c99c230ff
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 04 10:15:16 2012 +0200
x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()
There are two greater-than-zero checks for the old vector retrieved,
which don''t work when a negative value got stashed into the
respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).
This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25962:41f523f1b5e5
xen-unstable date: Fri Sep 28 07:23:34 UTC 2012
changeset: 25869:051661b76ade
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 04 10:14:44 2012 +0200
x86/HPET: don''t disable interrupt delivery right after setting it
up
We shouldn''t clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.
This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25961:6a5812129094
xen-unstable date: Fri Sep 28 07:22:14 UTC 2012
changeset: 25868:b4bda6995bc1
user: Daniel De Graaf <dgdegra@tycho.nsa.gov>
date: Thu Oct 04 10:13:55 2012 +0200
x86: check remote MMIO remap permissions
When a domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain''s
page
tables implies full access to the target domain, so checking that
domain''s permission is sufficient.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25952:8278d7d8fa48
xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
changeset: 25867:b0aed9cadf10
user: Ben Guthro <ben@guthro.net>
date: Thu Oct 04 10:12:43 2012 +0200
x86/S3: add cache flush on secondary CPUs before going to sleep
Secondary CPUs, between doing their final memory writes (particularly
updating cpu_initialized) and getting a subsequent INIT, may not write
back all modified data. The INIT itself then causes those modifications
to be lost, so in the cpu_initialized case the CPU would find itself
already initialized, (intentionally) entering an infinite loop instead
of actually coming online.
Signed-off-by: Ben Guthro <ben@guthro.net>
Make acpi_dead_idle() call default_dead_idle() rather than duplicating
the logic there.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25940:c8d65d91a6f2
xen-unstable date: Tue Sep 25 06:38:14 UTC 2012
changeset: 25866:ffabc1ebd913
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 04 10:11:11 2012 +0200
x86: tighten checks in XEN_DOMCTL_memory_mapping handler
Properly checking the MFN implies knowing the physical address width
supported by the platform, so to obtain this consistently the
respective code gets moved out of the MTRR subdir.
Btw., the model specific workaround in that code is likely unnecessary
- I believe those CPU models don''t support 64-bit mode. But I
wasn''t
able to formally verify this, so I preferred to retain that code for
now.
But domctl code here also was lacking other error checks (as was,
looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
Besides adding the missing checks, printing is also added for the case
where revoking access permissions didn''t work (as that may have
implications for the host operator, e.g. wanting to not pass through
affected devices to another guest until the one previously using them
did actually die).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25931:149805919569
xen-unstable date: Thu Sep 20 07:21:53 UTC 2012
changeset: 25865:63823a6785fc
user: Jan Beulich <jbeulich@suse.com>
date: Thu Oct 04 10:10:23 2012 +0200
x86: properly check XEN_DOMCTL_ioport_mapping arguments for invalid range
In particular, the case of "np" being a very large value
wasn''t handled
correctly. The range start checks also were off by one (except that in
practice, when "np" is properly range checked, this would still
have
been caught by the range end checks).
Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25927:3e3959413b2f
xen-unstable date: Wed Sep 19 07:27:55 UTC 2012
changeset: 25864:ca3e8190a72c
user: Ian Campbell <ian.campbell@citrix.com>
date: Tue Oct 02 16:02:10 2012 +0100
tools: bump SONAMEs for changes during 4.2 development cycle.
We mostly did this as we went along, only a couple of minor number
bumps were missed
http://marc.info/?l=xen-devel&m=134366054929255&w=2:
- Bumped libxl from 1.0.0 -> 1.0.1
- Bumped libxenstore from 3.0.1 -> 3.0.2
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25943:0a64f1a3f72c
Backport-requested-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)