flight 12190 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12190/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 guest-start fail REGR. vs. 12038
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 12038
test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail like 12033
test-amd64-i386-xl-credit2 5 xen-boot fail like 12038
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass
test-i386-i386-xl 15 guest-stop fail never pass
test-amd64-i386-xl 15 guest-stop fail never pass
test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass
test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass
test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass
test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 7 windows-install fail never pass
test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass
test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass
test-i386-i386-xl-winxpsp3 7 windows-install fail never pass
test-amd64-amd64-xl-win 7 windows-install fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass
test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass
version targeted for testing:
xen c62e9965b395
baseline version:
xen bf902d6661e3
------------------------------------------------------------
People who touched revisions under test:
Andres Lagar-Cavilla <andres@lagarcavilla.org>
Andrew Cooper <andrew.cooper3@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Olaf Hering <olaf@aepfle.de>
Tim Deegan <tim@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 fail
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd 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 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
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 pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf fail
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: 21576:c62e9965b395
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Wed Mar 07 09:09:05 2012 +0000
passthrough: release assigned PCI devices earlier during domain
shutdown
At least with xend, where there''s not even a tool stack side
attempt
to de-assign devices during domain shutdown, this allows immediate re-
starts of a domain to work reliably. (There''s no apparent reason
why
c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of
domain destruction).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24888:71159fb049f2
xen-unstable date: Fri Feb 24 11:46:32 2012 +0100
changeset: 21575:26bf0e10596e
user: Jan Beulich <jbeulich@suse.com>
date: Wed Mar 07 09:05:20 2012 +0000
x86/emulator: workaround for AMD erratum 573
The only cases where we might end up emulating fsincos (as any other
x87 operations without memory operands) are
- when a HVM guest is in real mode (not applicable on AMD)
- between two half page table updates in PAE mode (unlikely, and not
doing the emulation here does affect only performance, not
correctness)
- when a guest maliciously (or erroneously) modifies an (MMIO or page
table update) instruction under emulation (unspecified behavior)
Hence, in order to avoid the erratum to cause harm to the entire host,
don''t emulate fsincos on the affected AMD CPU families.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24417:1452fb248cd5
xen-unstable date: Fri Dec 16 15:45:40 2011 +0100
changeset: 21574:35ee60fe531f
user: Keir Fraser <keir@xen.org>
date: Wed Mar 07 09:04:11 2012 +0000
Fix build after previous changeset.
Signed-off-by: Keir Fraser <keir@xen.org>
changeset: 21573:cf5751788c49
user: Jan Beulich <jbeulich@suse.com>
date: Wed Mar 07 08:56:28 2012 +0000
x86, amd: Disable GartTlbWlkErr when BIOS forgets it
This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS
forgets to do is (or is just too old). Letting these errors enabled
can cause a sync-flood on the CPU causing a reboot.
The AMD BKDG recommends disabling GART TLB Wlk Error completely.
Based on a Linux patch from Joerg Roedel <joerg.roedel@amd.com>; see
e.g.
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24389:868d82faf651
xen-unstable date: Tue Dec 13 09:45:11 2011 +0100
changeset: 21572:fef96d880430
user: Andrew Cooper <andrew.cooper3@citrix.com>
date: Wed Mar 07 08:55:57 2012 +0000
KEXEC: fix kexec_get_range_compat to fail vocally.
Fail with -ERANGE rather than silently truncating 64bit values (a
physical address and size) into 32bit integers for dom0 to consume.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Simplify the bitwise arithmetic a bit.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24358:9961a6d5356a
xen-unstable date: Mon Dec 05 19:42:46 2011 +0000
changeset: 21571:32dbcf7567ea
user: Tim Deegan <tim@xen.org>
date: Wed Mar 07 08:54:24 2012 +0000
x86/mm: Don''t lose track of the log dirty bitmap
hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 24282:a06cda9fb25f
xen-unstable date: Thu Dec 01 14:17:16 2011 +0000
changeset: 21570:e4c5791fb484
user: Jan Beulich <jbeulich@suse.com>
date: Wed Mar 07 08:53:56 2012 +0000
x86: small fixes to pcpu platform op handling
XENPF_get_cpuinfo should init the flags output field rather than only
modify it.
XENPF_cpu_online must check for the input CPU number to be in range.
XENPF_cpu_offline must also do that, and should also reject attempts
to
offline CPU 0 (this fails in cpu_down() too, but preventing this here
appears more correct given that the code here calls
continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down()
would ever allow bringing down CPU 0 (and a distinct error code is
easier to deal with when debugging issues).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24201:9c6bea25f712
xen-unstable date: Thu Nov 24 17:56:26 2011 +0100
changeset: 21569:0cfc22ad014b
user: Andres Lagar-Cavilla <andres@lagarcavilla.org>
date: Wed Mar 07 08:51:51 2012 +0000
Trivial fix for rc val in hap track dirty vram
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24193:67d2ac426def
xen-unstable date: Thu Nov 24 15:44:51 2011 +0000
changeset: 21568:d4c7fac37dcf
user: Andres Lagar-Cavilla <andres@lagarcavilla.org>
date: Wed Mar 07 08:51:27 2012 +0000
x86/mm: change return code for log-dirty disabling
Disabling log dirty mode in HAP always returns -EINVAL. Make it
return the correct rc on success.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 24190:6b3d8250ee2c
xen-unstable date: Thu Nov 24 15:20:57 2011 +0000
changeset: 21567:b5575d7e462e
user: Jan Beulich <jbeulich@suse.com>
date: Wed Mar 07 08:50:55 2012 +0000
x86/vioapic: clear remote IRR when switching RTE to edge triggered
mode
Xen itself (as much as Linux) relies on this behavior, so it should
also emulate it properly. Not doing so reportedly gets in the way of
kexec inside a HVM guest.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
xen-unstable changeset: 24168:9c350ab8d3ea
xen-unstable date: Mon Nov 21 09:29:31 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>
changeset: 21566:17992e40806a
user: Jan Beulich <jbeulich@suse.com>
date: Wed Mar 07 08:50:32 2012 +0000
x86/IO-APIC: refine EOI-ing of migrating level interrupts
Rather than going through all IO-APICs and calling
io_apic_eoi_vector()
for the vector in question, just use eoi_IO_APIC_irq().
This in turn allows to eliminate quite a bit of other code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen-unstable changeset: 24155:0d50e704834f
xen-unstable date: Fri Nov 18 09:18:41 2011 +0100
changeset: 21565:bf902d6661e3
user: Ian Campbell <ian.campbell@citrix.com>
date: Thu Feb 23 10:41:33 2012 +0000
xen: add missing unlock from gnttab_get_version
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24871:66cc5b67e749
xen-unstable date: Thu Feb 23 09:59:35 2012 +0000
(qemu changes not included)