* [xen-unstable test] 24382: regressions - FAIL
@ 2014-01-16 4:51 xen.org
2014-01-16 8:33 ` Roger Pau Monné
0 siblings, 1 reply; 2+ messages in thread
From: xen.org @ 2014-01-16 4:51 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 24382 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/24382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 13 guest-localmigrate/x10 fail REGR. vs. 24375
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-win7-amd64 7 windows-install fail like 24380
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 9 guest-start fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 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-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen c04c825bdf1e946260cba325eeed993004051050
baseline version:
xen cfad12fd29637e4e5ede4a9ff15e2777e7a7d7b2
------------------------------------------------------------
People who touched revisions under test:
Anil Madhavapeddy <anil@recoil.org>
David Scott <dave.scott@eu.citrix.com>
Don Slutz <dslutz@verizon.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Julien Grall <julien.grall@linaro.org>
Mukesh Rathor <mukesh.rathor@oracle.com>
Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------
jobs:
build-amd64-xend pass
build-i386-xend pass
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-i386-freebsd10-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-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 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 c04c825bdf1e946260cba325eeed993004051050
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon Jan 13 18:15:37 2014 +0000
xl: Always use "fast" migration resume protocol
As Ian Campbell writes in http://bugs.xenproject.org/xen/bug/30:
There are two mechanisms by which a suspend can be aborted and the
original domain resumed.
The older method is that the toolstack resets a bunch of state (see
tools/python/xen/xend/XendDomainInfo.py resumeDomain) and then
restarts the domain. The domain will see HYPERVISOR_suspend return 0
and will continue without any realisation that it is actually
running in the original domain and not in a new one. This method is
supposed to be implemented by libxl_domain_resume(suspend_cancel=0)
but it is not.
The other method is newer and in this case the toolstack arranges
that HYPERVISOR_suspend returns SUSPEND_CANCEL and restarts it. The
domain will observe this and realise that it has been restarted in
the same domain and will behave accordingly. This method is
implemented, correctly AFAIK, by
libxl_domain_resume(suspend_cancel=1).
Attempting to use the old method without doing all of the work simply
causes the guest to crash. Implementing the work required for old
method, or for checking that domains actually support the new method,
is not feasible at this stage of the 4.4 release.
So, always use the new method, without regard to the declarations of
support by the guest. This is a strict improvement: guests which do
in fact support the new method will work, whereas ones which don't are
no worse off.
There are two call sites of libxl_domain_resume that need fixing, both
in the migration error path.
With this change I observe a correct and successful resumption of a
Debian wheezy guest with a Linux 3.4.70 kernel after a migration
attempt which I arranged to fail by nobbling the block hotplug script.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: konrad.wilk@oracle.com
CC: David Vrabel <david.vrabel@citrix.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
commit c63868ff0164fa1927b0d39f9aef5c7074ee04e2
Author: Wei Liu <wei.liu2@citrix.com>
Date: Mon Jan 13 11:52:28 2014 +0000
libxl: disallow PCI device assignment for HVM guest when PoD is enabled
This replicates a Xend behavior, see ec789523749 ("xend: Dis-allow
device assignment if PoD is enabled.").
This change is restricted to HVM guest, as only HVM is relevant in the
counterpart in Xend. We're late in release cycle so the change should
only do what's necessary. Probably we can revisit it if we need to do
the same thing for PV guest in the future.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
commit c938f5414b2b7ffa5b6f65daa9f4522db360987b
Author: Julien Grall <julien.grall@linaro.org>
Date: Tue Jan 14 13:36:55 2014 +0000
xen/arm: p2m: Correctly flush TLB in create_p2m_entries
The p2m is shared between VCPUs for each domain. Currently Xen only flush
TLB on the local PCPU. This could result to mismatch between the mapping in the
p2m and TLBs.
Flush TLB entries used by this domain on every PCPU. The flush can also be
moved out of the loop because:
- ALLOCATE: only called for dom0 RAM allocation, so the flush is never called
- INSERT: if valid = 1 that would means with have replaced a
page that already belongs to the domain. A VCPU can write on the wrong page.
This can happen for dom0 with the 1:1 mapping because the mapping is not
removed from the p2m.
- REMOVE: except for grant-table (replace_grant_host_mapping), each
call to guest_physmap_remove_page are protected by the callers via a
get_page -> .... -> guest_physmap_remove_page -> ... -> put_page. So
the page can't be allocated for another domain until the last put_page.
- RELINQUISH : the domain is not running anymore so we don't care...
Also avoid leaking a foreign page if the function is INSERTed a new mapping
on top of foreign mapping.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 8a9ab685bef64a50f58d99a4e8728b770289e9ef
Author: Julien Grall <julien.grall@linaro.org>
Date: Thu Jan 9 16:58:03 2014 +0000
xen/arm: correct flush_tlb_mask behaviour
On ARM, flush_tlb_mask is used in the common code:
- alloc_heap_pages: the flush is only be called if the new allocated
page was used by a domain before. So we need to flush only TLB non-secure
non-hyp inner-shareable.
- common/grant-table.c: every calls to flush_tlb_mask are used with
the current domain. A flush TLB by current VMID inner-shareable is enough.
The current code only flush hypervisor TLB on the current PCPU. For now,
flush TLBs non-secure non-hyp on every PCPUs.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 9b2691bdb499a3c2a136596658571056df1d42c8
Author: Anil Madhavapeddy <anil@recoil.org>
Date: Sat Jan 11 23:33:25 2014 +0000
libxl: ocaml: guard x86-specific functions behind an ifdef
The various cpuid functions are not available on ARM, so this
makes them raise an OCaml exception. Omitting the functions
completely results in a link failure in oxenstored due to the
missing symbols, so this is preferable to the much bigger patch
that would result from adding conditional compilation into the
OCaml interfaces.
With this patch, oxenstored can successfully start a domain on
Xen/ARM.
Signed-off-by: Anil Madhavapeddy <anil@recoil.org>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit f91dc2000a86d0af00f52b527fd28df00070f9cb
Author: Don Slutz <dslutz@verizon.com>
Date: Fri Jan 10 16:57:00 2014 -0500
xg_main: If XEN_DOMCTL_gdbsx_guestmemio fails then force error.
Without this gdb does not report an error.
With this patch and using a 1G hvm domU:
(gdb) x/1xh 0x6ae9168b
0x6ae9168b: Cannot access memory at address 0x6ae9168b
Drop output of iop->remain because it most likely will be zero.
This leads to a strange message:
ERROR: failed to read 0 bytes. errno:14 rc:-1
Add address to write error because it may be the only message
displayed.
Note: currently XEN_DOMCTL_gdbsx_guestmemio does not change 'iop' on
error and so iop->remain will be zero.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
commit dfbd3d62cd4a8e6e51be7896300e59c9ee0b8f82
Author: Don Slutz <dslutz@verizon.com>
Date: Fri Jan 10 16:56:59 2014 -0500
xg_read_mem: Report on error.
I had coded this with XGERR, but gdb will try to read memory without
a direct request from the user. So the error message can be confusing.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
(qemu changes not included)
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [xen-unstable test] 24382: regressions - FAIL
2014-01-16 4:51 [xen-unstable test] 24382: regressions - FAIL xen.org
@ 2014-01-16 8:33 ` Roger Pau Monné
0 siblings, 0 replies; 2+ messages in thread
From: Roger Pau Monné @ 2014-01-16 8:33 UTC (permalink / raw)
To: xen.org, xen-devel
On 16/01/14 05:51, xen.org wrote:
> flight 24382 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/24382/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-freebsd10-amd64 13 guest-localmigrate/x10 fail REGR. vs. 24375
The only relevant message I can find regarding this failure is from Qemu:
10000 when runstate is INMIGRATE
Which seems quite similar to the winxp failure in 24384:
xen_ram_alloc: do not alloc 1f800000 bytes of ram at 0 when runstate is
INMIGRATE
xen_ram_alloc: do not alloc 800000 bytes of ram at 1f800000 when
runstate is INMIGRATE
xen_ram_alloc: do not alloc 10000 bytes of ram at 20000000 when runstate
is INMIGRATE
xen_ram_alloc: do not alloc 40000 bytes of ram at 20010000 when runstate
is INMIGRATE
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-01-16 8:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-16 4:51 [xen-unstable test] 24382: regressions - FAIL xen.org
2014-01-16 8:33 ` Roger Pau Monné
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.