* [xen-4.2-testing test] 50412: regressions - FAIL
@ 2015-04-15 19:09 osstest service user
2015-04-16 8:25 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: osstest service user @ 2015-04-15 19:09 UTC (permalink / raw
To: xen-devel; +Cc: ian.jackson
flight 50412 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-freebsd10-i386 10 guest-start fail REGR. vs. 36512
test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
test-i386-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pair 9 xen-boot/src_host fail in 50395 pass in 50412
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 50395 pass in 50412
test-i386-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 50395
Tests which did not succeed, but are not blocking:
test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a
test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a
test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a
test-i386-i386-xl-qemuu-winxpsp3 16 guest-stop fail in 50395 never pass
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-i386-i386-xl-qemut-winxpsp3 16 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 16 guest-stop fail never pass
test-i386-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass
build-amd64-rumpuserxen 5 rumpuserxen-build fail never pass
test-i386-i386-xl-winxpsp3 16 guest-stop fail never pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass
test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass
build-i386-rumpuserxen 5 rumpuserxen-build fail never pass
test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/check fail never pass
test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
xen e3bfa4003ceaa2746cdd77655953ab2601acaf9c
baseline version:
xen 5bec01c19839e150e489dd04376c65f961830c86
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen fail
build-i386-rumpuserxen fail
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-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-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-qemuu-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-rumpuserxen-amd64 blocked
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-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-i386-i386-xl-credit2 pass
test-amd64-i386-qemuu-freebsd10-i386 fail
test-amd64-i386-rumpuserxen-i386 blocked
test-i386-i386-rumpuserxen-i386 blocked
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-amd64-i386-libvirt pass
test-i386-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-i386-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-i386-i386-pair fail
test-amd64-amd64-xl-sedf-pin pass
test-i386-i386-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-i386-i386-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-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-i386-i386-xl-qemut-winxpsp3 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 osstest.test-lab.xenproject.org
logs: /home/osstest/pub/logs
images: /home/osstest/pub/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit e3bfa4003ceaa2746cdd77655953ab2601acaf9c
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed Apr 1 10:12:19 2015 +0100
Limit XEN_DOMCTL_memory_mapping hypercall to only process up to 64 GFNs (or less)
Said hypercall for large BARs can take quite a while. As such
we can require that the hypercall MUST break up the request
in smaller values.
Another approach is to add preemption to it - whether we do the
preemption using hypercall_create_continuation or returning
EAGAIN to userspace (and have it re-invocate the call) - either
way the issue we cannot easily solve is that in 'map_mmio_regions'
if we encounter an error we MUST call 'unmap_mmio_regions' for the
whole BAR region.
Since the preemption would re-use input fields such as nr_mfns,
first_gfn, first_mfn - we would lose the original values -
and only undo what was done in the current round (i.e. ignoring
anything that was done prior to earlier preemptions).
Unless we re-used the return value as 'EAGAIN|nr_mfns_done<<10' but
that puts a limit (since the return value is a long) on the amount
of nr_mfns that can provided.
This patch sidesteps this problem by:
- Setting an hard limit of nr_mfns having to be 64 or less.
- Toolstack adjusts correspondingly to the nr_mfn limit.
- If the there is an error when adding the toolstack will call the
remove operation to remove the whole region.
The need to break this hypercall down is for large BARs can take
more than the guest (initial domain usually) time-slice. This has
the negative result in that the guest is locked out for a long
duration and is unable to act on any pending events.
We also augment the code to return zero if nr_mfns instead
of trying to the hypercall.
This is XSA-125 / CVE-2015-2752.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 70bca60d35f02f512548d15b62863d366461be6f
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue Mar 31 16:35:14 2015 +0100
QEMU_TAG update
(qemu changes not included)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.2-testing test] 50412: regressions - FAIL
2015-04-15 19:09 [xen-4.2-testing test] 50412: regressions - FAIL osstest service user
@ 2015-04-16 8:25 ` Jan Beulich
2015-04-16 15:21 ` Ian Jackson
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2015-04-16 8:25 UTC (permalink / raw
To: ian.jackson; +Cc: xen-devel
>>> On 15.04.15 at 21:09, <osstest@xenbits.xen.org> wrote:
> flight 50412 xen-4.2-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/50412/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-qemuu-freebsd10-i386 10 guest-start fail REGR. vs. 36512
> test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
> test-i386-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
These have been persistent since flight 50318. While for the 1st
one I can't immediately see what's going wrong, the 2nd and 3rd
ones suffer from full SWIOTLBs again on at least one of the two
hosts. Could they be told to use a larger SWIOTLB?
While looking at the serial log I also noticed that the kernel boot
messages end when the boot console gets disabled. That's may
end up being rather unhelpful going forward in case of issues
occurring during Dom0 boot. Can this be adjusted?
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.2-testing test] 50412: regressions - FAIL
2015-04-16 8:25 ` Jan Beulich
@ 2015-04-16 15:21 ` Ian Jackson
2015-04-16 15:59 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Ian Jackson @ 2015-04-16 15:21 UTC (permalink / raw
To: Jan Beulich; +Cc: xen-devel
Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 50412: regressions - FAIL"):
> On 15.04.15 at 21:09, <osstest@xenbits.xen.org> wrote:
> > test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
> > test-i386-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
>
> These have been persistent since flight 50318. While for the 1st
> one I can't immediately see what's going wrong, the 2nd and 3rd
> ones suffer from full SWIOTLBs again on at least one of the two
> hosts. Could they be told to use a larger SWIOTLB?
Hrm. I hadn't noticed that this was a swiotlb problem.
I'm not convinced it would be correct to add an override to osstest to
specify a larger swiotlb. These tests are not doing anything
particularly strange.
If the swiotlb is too small then surely that is a kernel tuning bug.
However, I could be persuaded to add a boot option to increase the
swiotlb size as a workaround for these specific machines if you think
it might help. Would you care to specify a specific command line
option ?
Also, are you sure this isn't our longstanding swiotlb dma bug, that
some of the machines in the old colo also had ?
Ian.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.2-testing test] 50412: regressions - FAIL
2015-04-16 15:21 ` Ian Jackson
@ 2015-04-16 15:59 ` Jan Beulich
0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2015-04-16 15:59 UTC (permalink / raw
To: Ian Jackson; +Cc: xen-devel
>>> On 16.04.15 at 17:21, <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 50412: regressions -
> FAIL"):
>> On 15.04.15 at 21:09, <osstest@xenbits.xen.org> wrote:
>> > test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
>> > test-i386-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36512
>>
>> These have been persistent since flight 50318. While for the 1st
>> one I can't immediately see what's going wrong, the 2nd and 3rd
>> ones suffer from full SWIOTLBs again on at least one of the two
>> hosts. Could they be told to use a larger SWIOTLB?
>
> Hrm. I hadn't noticed that this was a swiotlb problem.
>
> I'm not convinced it would be correct to add an override to osstest to
> specify a larger swiotlb. These tests are not doing anything
> particularly strange.
>
> If the swiotlb is too small then surely that is a kernel tuning bug.
Quite possible, albeit determining the right size is a tough thing to
do, as the kernel - at the time it needs the size - has no idea how
many and what kind of devices it'll have to be able to handle.
> However, I could be persuaded to add a boot option to increase the
> swiotlb size as a workaround for these specific machines if you think
> it might help. Would you care to specify a specific command line
> option ?
Not really, as this very much depends on system and load. I'm
afraid that would need to be determined experimentally.
> Also, are you sure this isn't our longstanding swiotlb dma bug, that
> some of the machines in the old colo also had ?
No, I'm not sure about this at all.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-16 15:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-15 19:09 [xen-4.2-testing test] 50412: regressions - FAIL osstest service user
2015-04-16 8:25 ` Jan Beulich
2015-04-16 15:21 ` Ian Jackson
2015-04-16 15:59 ` Jan Beulich
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.