* [xen-4.9-testing test] 132484: regressions - FAIL
@ 2019-01-29 18:49 osstest service owner
2019-01-29 18:55 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: osstest service owner @ 2019-01-29 18:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 132484 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130954
test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 130954
build-armhf-libvirt 6 libvirt-build fail REGR. vs. 130954
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail blocked in 130954
test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail like 130851
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 130890
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 130954
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 130954
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 130954
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 130954
test-amd64-amd64-xl-rtds 10 debian-install fail like 130954
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 130954
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
xen 19fc44f4a180158f27788e60f6da78ea29f68a33
baseline version:
xen 7f01558d9b3fc4011741e9f469c96fd93dd8454e
Last test of basis 130954 2018-12-03 03:12:41 Z 57 days
Testing same since 132484 2019-01-26 01:36:39 Z 3 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Julien Grall <julien.grall@arm.com>
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Stefano Stabellini <sstabellini@kernel.org>
Stefano Stabellini <stefanos@xilinx.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt fail
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 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 pass
test-amd64-amd64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-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-rumprun-amd64 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-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch 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 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw blocked
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 19fc44f4a180158f27788e60f6da78ea29f68a33
Author: Julien Grall <julien.grall@arm.com>
Date: Mon Oct 1 17:42:26 2018 +0100
xen/arm: vgic-v3: Delay the initialization of the domain information
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain structure. However this information is
not available at domain creation. This is only known once
XEN_DOMCTL_max_vpus is called for that domain.
In order to get the max vCPUs around, delay the domain part of the vGIC
v3 initialization until the first vCPU of the domain is initialized.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Acked-but-disliked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db)
commit 97b37e342b0abe2c3d5c5ce8ffe884cb20c85be5
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Tue Nov 13 08:45:49 2018 -0800
xen/arm: check for multiboot nodes only under /chosen
Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).
Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
[julien: Use sizeof(path) instead of len ]
Reviewed-by: Julien Grall <julien.grall@arm.com>
(cherry picked from commit c32e3689c546305d4eae53e6ccf9c8b4e048c7df)
commit 2d57b55a0def0cc636302821fb6e1ce1aef7f947
Author: Julien Grall <julien.grall@arm.com>
Date: Tue Oct 23 19:17:07 2018 +0100
xen/arm: gic: Ensure ordering between read of INTACK and shared data
When an IPI is generated by a CPU, the pattern looks roughly like:
<write shared data>
dsb(sy);
<write to GIC to signal SGI>
On the receiving CPU we rely on the fact that, once we've taken the
interrupt, then the freshly written shared data must be visible to us.
Put another way, the CPU isn't going to speculate taking an interrupt.
Unfortunately, this assumption turns out to be broken.
Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
to read some shared_data. Before CPUx has done anything, a random
peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
CPUy then takes the IRQ and starts executing the entry code, heading
towards gic_handle_irq. Furthermore, let's assume that a bunch of the
previous interrupts handled by CPUy were SGIs, so the branch predictor
kicks in and speculates that irqnr will be <16 and we're likely to
head into handle_IPI. The prefetcher then grabs a speculative copy of
shared_data which contains a stale value.
Meanwhile, CPUx gets round to updating shared_data and asking the GIC
to send an SGI to CPUy. Internally, the GIC decides that the SGI is
more important than the peripheral interrupt (which hasn't yet been
ACKed) but doesn't need to do anything to CPUy, because the IRQ line
is already raised.
CPUy then reads the ACK register on the GIC, sees the SGI value which
confirms the branch prediction and we end up with a stale shared_data
value.
This patch fixes the problem by adding an smp_rmb() to the IPI entry
code in do_SGI.
At the same time document the write barrier.
Based on Linux commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496
"irqchip/gic: Ensure ordering between read of INTACK and shared data".
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov<andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 555e5f1bd26c4c1995357e9671b3e42a68d5ce8f)
commit a3b22eb0c46052b3136352e81497e290e6d17556
Author: Julien Grall <julien.grall@arm.com>
Date: Tue Oct 23 19:17:06 2018 +0100
xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()
Devices that expose their interrupt status registers via system
registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
vgic (although unused by Linux), ...) rely on a context synchronising
operation on the CPU to ensure that the updated status register is
visible to the CPU when handling the interrupt. This usually happens as
a result of taking the IRQ exception in the first place, but there are
two race scenarios where this isn't the case.
For example, let's say we have two peripherals (X and Y), where Y uses a
system register for its interrupt status.
Case 1:
1. CPU takes an IRQ exception as a result of X raising an interrupt
2. Y then raises its interrupt line, but the update to its system
register is not yet visible to the CPU
3. The GIC decides to expose Y's interrupt number first in the Ack
register
4. The CPU runs the IRQ handler for Y, but the status register is stale
Case 2:
1. CPU takes an IRQ exception as a result of X raising an interrupt
2. CPU reads the interrupt number for X from the Ack register and runs
its IRQ handler
3. Y raises its interrupt line and the Ack register is updated, but
again, the update to its system register is not yet visible to the
CPU.
4. Since the GIC drivers poll the Ack register, we read Y's interrupt
number and run its handler without a context synchronisation
operation, therefore seeing the stale register value.
In either case, we run the risk of missing an IRQ. This patch solves the
problem by ensuring that we execute an ISB in the GIC drivers prior
to invoking the interrupt handler.
Based on Linux commit 39a06b67c2c1256bcf2361a1f67d2529f70ab206
"irqchip/gic: Ensure we have an ISB between ack and ->handle_irq".
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov<andrii_anisov@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 177afec4556c676e5a1a958d1626226fbca2a696)
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.9-testing test] 132484: regressions - FAIL
2019-01-29 18:49 [xen-4.9-testing test] 132484: regressions - FAIL osstest service owner
@ 2019-01-29 18:55 ` Andrew Cooper
2019-01-30 12:43 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2019-01-29 18:55 UTC (permalink / raw)
To: xen-devel; +Cc: Jan Beulich
On 29/01/2019 18:49, osstest service owner wrote:
> flight 132484 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/132484/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130954
This is the XSA-278 PoC noticing that c/s
75ce36eb72cb93e8a3c9f60fd5e697067921d712 hasn't been backported.
It is exceedingly machine specific as to whether the problem manifests.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.9-testing test] 132484: regressions - FAIL
2019-01-29 18:55 ` Andrew Cooper
@ 2019-01-30 12:43 ` Jan Beulich
2019-01-30 12:50 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2019-01-30 12:43 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel
>>> On 29.01.19 at 19:55, <andrew.cooper3@citrix.com> wrote:
> On 29/01/2019 18:49, osstest service owner wrote:
>> flight 132484 xen-4.9-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/132484/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130954
>
> This is the XSA-278 PoC noticing that c/s
> 75ce36eb72cb93e8a3c9f60fd5e697067921d712 hasn't been backported.
I've just added this to the pending set, but I have to admit that
it wasn't clear to me at all that this would be needed on the stable
trees. There was a remark about backportability in the submission,
but this didn't mean to me that it's kind of imperative to have.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.9-testing test] 132484: regressions - FAIL
2019-01-30 12:43 ` Jan Beulich
@ 2019-01-30 12:50 ` Andrew Cooper
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cooper @ 2019-01-30 12:50 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
On 30/01/2019 12:43, Jan Beulich wrote:
>>>> On 29.01.19 at 19:55, <andrew.cooper3@citrix.com> wrote:
>> On 29/01/2019 18:49, osstest service owner wrote:
>>> flight 132484 xen-4.9-testing real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/132484/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130954
>> This is the XSA-278 PoC noticing that c/s
>> 75ce36eb72cb93e8a3c9f60fd5e697067921d712 hasn't been backported.
> I've just added this to the pending set, but I have to admit that
> it wasn't clear to me at all that this would be needed on the stable
> trees. There was a remark about backportability in the submission,
> but this didn't mean to me that it's kind of imperative to have.
This particular bug (and bugfix) was found completely unexpectedly by
the XSA-278 PoC.
There is no critical need to backport the bugfix (as it is indeed
benign), except for the fact that because OSSTest has observed that the
PoC fails on that specific hardware, it has come to the (incorrect)
conclusion that we've recently regressed the 4.9 branch.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-30 12:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-29 18:49 [xen-4.9-testing test] 132484: regressions - FAIL osstest service owner
2019-01-29 18:55 ` Andrew Cooper
2019-01-30 12:43 ` Jan Beulich
2019-01-30 12:50 ` Andrew Cooper
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.