flight 15421 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15421/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 15417
test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 15417
test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail REGR. vs. 15417
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15417
test-amd64-i386-xend-winxpsp3 7 windows-install fail REGR. vs. 15417
test-amd64-i386-win 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 15417
test-amd64-i386-xend-qemut-winxpsp3 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 15417
test-amd64-i386-qemut-win-vcpus1 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 15417
test-amd64-i386-xl-win-vcpus1 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-qemut-win 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 15417
test-amd64-i386-win-vcpus1 7 windows-install fail REGR. vs. 15417
test-amd64-amd64-win 7 windows-install fail REGR. vs. 15417
test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 15417
test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 15417
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 5 xen-boot fail like 15417
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail like 15417
test-amd64-amd64-xl-qemut-win 7 windows-install fail like 15417
Tests which did not succeed, but are not blocking:
build-armhf 4 xen-build fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen ff77e84ddfdc
baseline version:
xen d1bf3b21f783
------------------------------------------------------------
People who touched revisions under test:
Dongxiao Xu <dongxiao.xu@intel.com>
Eddie Dong <eddie.dong@intel.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf fail
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-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 fail
test-amd64-i386-qemut-rhel6hvm-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-qemut-win-vcpus1 fail
test-amd64-i386-xl-qemut-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-amd64-amd64-qemut-win fail
test-amd64-i386-qemut-win fail
test-amd64-amd64-xl-qemut-win fail
test-amd64-amd64-xl-win 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.
------------------------------------------------------------
changeset: 26506:ff77e84ddfdc
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Mon Feb 04 12:10:26 2013 +0100
x86/EFI: simplify PCI option ROM retrieval
While putting together the kernel side of this I realized that c/s
26397:d9c7b82aa7b1 went a little too far in requiring a buffer for the
option ROM contents - all that is really needed is handing Dom0
physical address and size of the data block.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 26505:de6160ccaf9d
user: Dongxiao Xu <dongxiao.xu@intel.com>
date: Mon Feb 04 12:08:15 2013 +0100
nEPT: fix INVEPT instruction parameter
While emulating the INVEPT instruction in L0 VMM, the EPT pointer
should be fetched from the instruction decoding result, but not
the current loaded EPT pointer.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
changeset: 26504:90525fcb0982
user: Dongxiao Xu <dongxiao.xu@intel.com>
date: Mon Feb 04 12:07:34 2013 +0100
nEPT: fix EPT pointer setting for L2 guest
Each time in virtual_vmentry(), the code needs to cover both EPT
and shadow mode for L2 guest, updating different EPT pointer to
shadow VMCS.
This fixes the issue that, launch a guest with EPT, then kill it
and launch a second guest with shadow, the second guest will hang
at the startup screen.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Acked by: Eddie Dong <eddie.dong@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
changeset: 26503:69398345c10e
user: Jan Beulich <jbeulich@suse.com>
date: Mon Feb 04 12:03:38 2013 +0100
x86/nestedhvm: properly clean up after failure to set up all vCPU-s
This implies that the individual destroy functions will have to remain
capable of being called for a vCPU that the corresponding init function
was never run on.
Once at it, also clean up some inefficiencies in the corresponding
parameter validation code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 26502:d1bf3b21f783
user: Dongxiao Xu <dongxiao.xu@intel.com>
date: Wed Jan 30 09:17:30 2013 -0800
VMX: disable SMEP feature when guest is in non-paging mode
SMEP is disabled if CPU is in non-paging mode in hardware.
However Xen always uses paging mode to emulate guest non-paging
mode with HAP. To emulate this behavior, SMEP needs to be manually
disabled when guest switches to non-paging mode.
We met an issue that, SMP Linux guest with recent kernel (enable
SMEP support, for example, 3.5.3) would crash with triple fault if
setting unrestricted_guest=0 in grub. This is because Xen uses an
identity mapping page table to emulate the non-paging mode, where
the page table is set with USER flag. If SMEP is still enabled in
this case, guest will meet unhandlable page fault and then crash.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
=======================================commit
2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu Jan 17 15:52:16 2013 +0000
e1000: fix compile warning introduced by security fix, and debugging
e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
hw/e1000.c:641: warning: ''return'' with a value, in
function returning void
In upstream qemu (where this change came from), e1000_receive returns
a value used by queueing machinery to decide whether to try
resubmitting the packet later. Returning "size" means that the
packet
has been dealt with and should not be retried.
In this old branch (aka qemu-xen-traditional), this machinery is
absent and e1000_receive returns void. Fix the return statement.
Also add a debugging statement along the lines of the others in this
function.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>