* [xen-unstable baseline-only test] 38238: tolerable FAIL
@ 2015-11-02 14:18 Platform Team regression test user
0 siblings, 0 replies; only message in thread
From: Platform Team regression test user @ 2015-11-02 14:18 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 20972 bytes --]
This run is configured for baseline tests only.
flight 38238 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38238/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-pygrub 20 guest-start/debian.repeat fail blocked in 38227
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 38227
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 38227
test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail like 38227
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail never pass
test-armhf-armhf-xl-vhd 9 debian-di-install fail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-install fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail never pass
test-armhf-armhf-libvirt 14 guest-saverestore fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-armhf-armhf-xl-midway 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-midway 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
version targeted for testing:
xen e294a0c3af9f4443dc692b180fb1771b1cb075e8
baseline version:
xen b261366f10eb150458d28aa728d399d0a781997e
Last test of basis 38227 2015-10-30 08:20:16 Z 3 days
Testing same since 38238 2015-11-02 05:50:17 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Dario Faggioli <dario.faggioli@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
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-prev pass
build-i386-prev 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-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 fail
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
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 fail
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 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 pass
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 fail
test-amd64-i386-libvirt pass
test-armhf-armhf-xl-midway pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
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 fail
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
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 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
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
Push not applicable.
------------------------------------------------------------
commit e294a0c3af9f4443dc692b180fb1771b1cb075e8
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed Oct 21 16:18:30 2015 +0100
libxl: adjust PoD target by memory fudge, too
PoD guests need to balloon at least as far as required by PoD, or risk
crashing. Currently they don't necessarily know what the right value
is, because our memory accounting is (at the very least) confusing.
Apply the memory limit fudge factor to the in-hypervisor PoD memory
target, too. This will increase the size of the guest's PoD cache by
the fudge factor LIBXL_MAXMEM_CONSTANT (currently 1Mby). This ensures
that even with a slightly-off balloon driver, the guest will be
stable even under memory pressure.
There are two call sites of xc_domain_set_pod_target that need fixing:
The one in libxl_set_memory_target is straightforward.
The one in xc_hvm_build_x86.c:setup_guest is more awkward. Simply
setting the PoD target differently does not work because the various
amounts of memory during domain construction no longer match up.
Instead, we adjust the guest memory target in xenstore (but only for
PoD guests).
This introduces a 1Mby discrepancy between the balloon target of a PoD
guest at boot, and the target set by an apparently-equivalent `xl
mem-set' (or similar) later. This approach is low-risk for a security
fix but we need to fix this up properly in xen.git#staging and
probably also in stable trees.
This is XSA-153.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
(cherry picked from commit 56fb5fd62320eb40a7517206f9706aa9188d6f7b)
commit 95e7415843b94c346e5ba8682665f508f220e04b
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Oct 29 13:37:19 2015 +0100
x86: rate-limit logging in do_xen{oprof,pmu}_op()
Some of the sub-ops are acessible to all guests, and hence should be
rate-limited. In the xenoprof case, just like for XSA-146, include them
only in debug builds. Since the vPMU code is rather new, allow them to
be always present, but downgrade them to (rate limited) guest messages.
This is CVE-2015-7971 / XSA-152.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
commit 6e97c4b37386c2d09e09e9b5d5d232e37728b960
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Oct 29 13:36:52 2015 +0100
xenoprof: free domain's vcpu array
This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
guest").
This is CVE-2015-7969 / XSA-151.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
commit 101ce53266866144e724ed593173bc4098b300b9
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Oct 29 13:36:25 2015 +0100
x86/PoD: Eager sweep for zeroed pages
Based on the contents of a guests physical address space,
p2m_pod_emergency_sweep() could degrade into a linear memcmp() from 0 to
max_gfn, which runs non-preemptibly.
As p2m_pod_emergency_sweep() runs behind the scenes in a number of contexts,
making it preemptible is not feasible.
Instead, a different approach is taken. Recently-populated pages are eagerly
checked for reclaimation, which amortises the p2m_pod_emergency_sweep()
operation across each p2m_pod_demand_populate() operation.
Note that in the case that a 2M superpage can't be reclaimed as a superpage,
it is shattered if 4K pages of zeros can be reclaimed. This is unfortunate
but matches the previous behaviour, and is required to avoid regressions
(domain crash from PoD exhaustion) with VMs configured close to the limit.
This is CVE-2015-7970 / XSA-150.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit d46896ebbb23f3a9fef2eb6066ae614fd1acfd96
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Oct 29 13:35:40 2015 +0100
free domain's vcpu array
This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
guest").
This is CVE-2015-7969 / XSA-149.
Reported-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
commit fe360c90ea13f309ef78810f1a2b92f2ae3b30b8
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Oct 29 13:35:07 2015 +0100
x86: guard against undue super page PTE creation
When optional super page support got added (commit bd1cd81d64 "x86: PV
support for hugepages"), two adjustments were missed: mod_l2_entry()
needs to consider the PSE and RW bits when deciding whether to use the
fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK
unconditionally.
This is CVE-2015-7835 / XSA-148.
Reported-by: "æ ¾å°èª(好é£)" <shangcong.lsc@alibaba-inc.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 1ef01396fdff88b1c3331a09ca5c69619b90f4ea
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Oct 29 13:34:17 2015 +0100
arm: handle races between relinquish_memory and free_domheap_pages
Primarily this means XENMEM_decrease_reservation from a toolstack
domain.
Unlike x86 we have no requirement right now to queue such pages onto
a separate list, if we hit this race then the other code has already
fully accepted responsibility for freeing this page and therefore
there is no more for relinquish_memory to do.
This is CVE-2015-7814 / XSA-147.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 1c0e59ff15764e7b0c59282365974f5b8924ce83
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Oct 29 13:33:38 2015 +0100
arm: rate-limit logging from unimplemented PHYSDEVOP and HVMOP.
These are guest accessible and should therefore be rate-limited.
Moreover, include them only in debug builds.
This is CVE-2015-7813 / XSA-146.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 29bcf64ce8bc0b1b7aacd00c8668f255c4f0686c
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 29 13:31:10 2015 +0100
arm: Support hypercall_create_continuation for multicall
Multicall for ARM has been supported since commit f0dbdc6 "xen: arm: fully
implement multicall interface.". Although, if an hypercall in multicall
requires preemption, it will crash the host:
(XEN) Xen BUG at domain.c:347
(XEN) ----[ Xen-4.7-unstable arm64 debug=y Tainted: C ]----
[...]
(XEN) Xen call trace:
(XEN) [<00000000002420cc>] hypercall_create_continuation+0x64/0x380 (PC)
(XEN) [<0000000000217274>] do_memory_op+0x1b00/0x2334 (LR)
(XEN) [<0000000000250d2c>] do_multicall_call+0x114/0x124
(XEN) [<0000000000217ff0>] do_multicall+0x17c/0x23c
(XEN) [<000000000024f97c>] do_trap_hypercall+0x90/0x12c
(XEN) [<0000000000251ca8>] do_trap_hypervisor+0xd2c/0x1ba4
(XEN) [<00000000002582cc>] guest_sync+0x88/0xb8
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 5:
(XEN) Xen BUG at domain.c:347
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
Looking to the code, the support of multicall looks valid to me, as we only
need to fill call.args[...]. So drop the BUG();
This is CVE-2015-7812 / XSA-145.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 79fbab823fde327c6b766529c1b06b509457dc92
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 29 12:24:13 2015 +0100
sched-rt: avoid to shadow the variable "svc" in rt_dom_cntl
The variable "svc" is declared twice within rt_dom_cntl. However, the
top declaration could be re-used avoiding re-declaring another time the
variable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
commit 568ff32927ecc68765973ad5b590b48e045dee4a
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 29 12:23:53 2015 +0100
credit2: avoid to shadow the variable "cur" in runq_tickle
The variable "cur" is declared twice within "cur". However the top
declaration could be re-used avoiding re-declaring another time the
variable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 4c09af65a9afeabd381b132a21dd8eaeee7e8437
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 29 12:23:34 2015 +0100
common/memory: avoid to shadow the variable "d" in do_memory_op
The variable "d" is declared multiple times within do_memory_op.
The subsequent declaration are not useful because the top one is never
used. So drop them.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 5a722f89d30093cf5e1d2bc536fd73d6f9e5513f
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 29 12:20:38 2015 +0100
grant_table: avoid to shadow "frame" in __gnttab_map_grant_ref
The variable "frame" is declared twice within the function
__gntab_map_grant_ref. This makes the code quite confusing to read.
The second definition is not useful as the first one is never used
until then. So drop it.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit f6f08decb5f24ac299ab2ce23e2164ed8b13ca50
Author: Julien Grall <julien.grall@citrix.com>
Date: Thu Oct 29 12:19:23 2015 +0100
common/domain: avoid to shadow the variable "d" in do_vcpu_op
The variable "d" is defined twice. However, the second one is not
necessary as the vCPU as already been deduced from the first "d".
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
(qemu changes not included)
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2015-11-02 14:18 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-02 14:18 [xen-unstable baseline-only test] 38238: tolerable FAIL Platform Team regression test user
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.