* [xen-unstable-smoke test] 117106: trouble: blocked/broken
@ 2017-12-14 2:40 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2017-12-14 2:40 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 117106 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117106/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 <job status> broken
test-arm64-arm64-xl-xsm <job status> broken
build-armhf <job status> broken
build-armhf 4 host-install(4) broken REGR. vs. 116956
build-amd64 4 host-install(4) broken REGR. vs. 116956
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
version targeted for testing:
xen b95f7be32d668fa4b09300892ebe19636ecebe36
baseline version:
xen 43550972395f9a3a48bb4086a0faf0f8d442e37d
Last test of basis 116956 2017-12-07 23:02:27 Z 6 days
Failing since 117015 2017-12-08 22:03:21 Z 5 days 12 attempts
Testing same since 117106 2017-12-12 18:02:13 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andre Przywara <andre.przywara@arm.com>
Andre Przywara <andre.przywara@linaro.org>
Andrew Cooper <andrew.cooper3@citrix.com>
Daniel Kiper <daniel.kiper@oracle.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Julien Grall <julien.grall@linaro.org>
Stefano Stabellini <sstabellini@kernel.org>
jobs:
build-amd64 broken
build-armhf broken
build-amd64-libvirt blocked
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm broken
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
------------------------------------------------------------
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
broken-job build-amd64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-armhf broken
broken-step build-armhf host-install(4)
broken-step build-amd64 host-install(4)
Not pushing.
------------------------------------------------------------
commit b95f7be32d668fa4b09300892ebe19636ecebe36
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 16:56:15 2017 +0100
x86/mm: drop bogus paging mode assertion
Olaf has observed this assertion to trigger after an aborted migration
of a PV guest:
(XEN) Xen call trace:
(XEN) [<ffff82d0802a85dc>] do_page_fault+0x39f/0x55c
(XEN) [<ffff82d08036b7d8>] x86_64/entry.S#handle_exception_saved+0x66/0xa4
(XEN) [<ffff82d0802a9274>] __copy_to_user_ll+0x22/0x30
(XEN) [<ffff82d0802772d4>] update_runstate_area+0x19c/0x228
(XEN) [<ffff82d080277371>] domain.c#_update_runstate_area+0x11/0x39
(XEN) [<ffff82d080277596>] context_switch+0x1fd/0xf25
(XEN) [<ffff82d0802395c5>] schedule.c#schedule+0x303/0x6a8
(XEN) [<ffff82d08023d067>] softirq.c#__do_softirq+0x6c/0x95
(XEN) [<ffff82d08023d0da>] do_softirq+0x13/0x15
(XEN) [<ffff82d08036b2f1>] x86_64/entry.S#process_softirqs+0x21/0x30
Release builds work fine, which is a first indication that the assertion
isn't really needed.
What's worse though - there appears to be a timing window where the
guest runs in shadow mode, but not in log-dirty mode, and that is what
triggers the assertion (the same could, afaict, be achieved by test-
enabling shadow mode on a PV guest). This is because turing off log-
dirty mode is being performed in two steps: First the log-dirty bit gets
cleared (paging_log_dirty_disable() [having paused the domain] ->
sh_disable_log_dirty() -> shadow_one_bit_disable()), followed by
unpausing the domain and only then clearing shadow mode (via
shadow_test_disable(), which pauses the domain a second time).
Hence besides removing the ASSERT() here (or optionally replacing it by
explicit translate and refcounts mode checks, but this seems rather
pointless now that the three are tied together) I wonder whether either
shadow_one_bit_disable() should turn off shadow mode if no other bit
besides PG_SH_enable remains set (just like shadow_one_bit_enable()
enables it if not already set), or the domain pausing scope should be
extended so that both steps occur without the domain getting a chance to
run in between.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 7f1061938415f0d93d7ee6040e49236d2e050627
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 14:31:55 2017 +0100
x86emul: build SIMD tests with -Os
Specifically in the context of putting together subsequent patches I've
noticed that together with the touch() macro using -Os further
increases the chances of the compiler using memory operands for the
instructions we actually care to test.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 9589927e5bf9e123ec42b6e0b0809f153bd92732
Author: Daniel Kiper <daniel.kiper@oracle.com>
Date: Tue Dec 12 14:30:53 2017 +0100
x86/mb2: avoid Xen image when looking for module/crashkernel position
Commit e22e1c4 (x86/EFI: avoid Xen image when looking for module/kexec
position) added relevant check for EFI case. However, since commit
f75a304 (x86: add multiboot2 protocol support for relocatable images)
Multiboot2 compatible bootloaders are able to relocate Xen image too.
So, we have to avoid also Xen image region in such cases.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit b4d0218cff66b7eaa9c9b8dc9bd71e7b089b016d
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 14:30:17 2017 +0100
x86/paging: don't unconditionally BUG() on finding SHARED_M2P_ENTRY
PV guests can fully control the values written into the P2M.
This is XSA-251.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 10be8001de7d87be1f0ccdda75cc70e922e56d03
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 14:29:45 2017 +0100
x86/shadow: fix ref-counting error handling
The old-Linux handling in shadow_set_l4e() mistakenly ORed together the
results of sh_get_ref() and sh_pin(). As the latter failing is not a
correctness problem, simply ignore its return value.
In sh_set_toplevel_shadow() a failing sh_get_ref() must not be
accompanied by installing the entry, despite the domain being crashed.
This is XSA-250.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit 54e2292e8df7a1a7b041192be9d6d797b6d00869
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 14:29:13 2017 +0100
x86/shadow: fix refcount overflow check
Commit c385d27079 ("x86 shadow: for multi-page shadows, explicitly track
the first page") reduced the refcount width to 25, without adjusting the
overflow check. Eliminate the disconnect by using a manifest constant.
Interestingly, up to commit 047782fa01 ("Out-of-sync L1 shadows: OOS
snapshot") the refcount was 27 bits wide, yet the check was already
using 26.
This is XSA-249.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
commit ff2a793e15bb0b6254bc849ef8e83e1c284c3583
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 14:28:36 2017 +0100
x86/mm: don't wrongly set page ownership
PV domains can obtain mappings of any pages owned by the correct domain,
including ones that aren't actually assigned as "normal" RAM, but used
by Xen internally. At the moment such "internal" pages marked as owned
by a guest include pages used to track logdirty bits, as well as p2m
pages and the "unpaged pagetable" for HVM guests. Since the PV memory
management and shadow code conflict in their use of struct page_info
fields, and since shadow code is being used for log-dirty handling for
PV domains, pages coming from the shadow pool must, for PV domains, not
have the domain set as their owner.
While the change could be done conditionally for just the PV case in
shadow code, do it unconditionally (and for consistency also for HAP),
just to be on the safe side.
There's one special case though for shadow code: The page table used for
running a HVM guest in unpaged mode is subject to get_page() (in
set_shadow_status()) and hence must have its owner set.
This is XSA-248.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
commit e40b0219a8c77741ae48989efb520f4a762a5be3
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Dec 12 14:27:34 2017 +0100
x86: don't wrongly trigger linear page table assertion (2)
_put_final_page_type(), when free_page_type() has exited early to allow
for preemption, should not update the time stamp, as the page continues
to retain the typ which is in the process of being unvalidated. I can't
see why the time stamp update was put on that path in the first place
(albeit it may well have been me who had put it there years ago).
This is part of XSA-240.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap.com>
commit c6c2fc6e4919a1420096b94a4ba8682f20e92709
Author: Julien Grall <julien.grall@linaro.org>
Date: Wed Nov 1 14:03:14 2017 +0000
xen/arm32: mm: Rework is_xen_heap_page to avoid nameclash
The arm32 version of the function is_xen_heap_page currently define a
variable _mfn. This will lead to a compiler when use typesafe MFN in a
follow-up patch:
called object '_mfn' is not a function or function pointer
Fix it by renaming the local variable _mfn to mfn_.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit 4da2ec1b1584975012ceda49160bd2f276076d5d
Author: Julien Grall <julien.grall@linaro.org>
Date: Wed Nov 1 14:03:13 2017 +0000
xen/arm: domain_build: Clean-up insert_11_bank
- Remove spurious ()
- Add missing spaces
- Turn 1 << to 1UL <<
- Rename spfn to smfn and switch to mfn_t
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9
Author: Andre Przywara <andre.przywara@linaro.org>
Date: Thu Dec 7 16:14:08 2017 +0000
ARM: VGIC: move gic_remove_irq_from_queues()
gic_remove_irq_from_queues() was not only misnamed, it also has the wrong
abstraction, as it should not live in gic.c.
Move it into vgic.c and vgic.h, where it belongs to, and rename it on
the way.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit 9630c5ae363b4cbf8eb61366530f40c80680af4d
Author: Julien Grall <julien.grall@arm.com>
Date: Wed Dec 6 14:51:37 2017 +0000
xen/arm: gic-v3: Bail out if gicv3_cpu_init fail
When system registers are not enabled, all the access to them will trap
in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only
on success. As the rest of the code (e.g gicv3_hyp_init) relies on
system register, it is better to bail out directly.
This will save time on debugging early boot issue on GICv3 platform.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit ac2d8d402370f6f93f82871f3b34ddb9a9ccae05
Author: Julien Grall <julien.grall@linaro.org>
Date: Wed Nov 29 17:46:35 2017 +0000
xen/arm: Surround HSR_SYSREG macro value with ()
The value of the macro HCR_SYSREG is not surrounded by (). This means
the behavior may change depend on how it is used.
Thanksfully recent GCC will issue a warning for that.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit b819187a15ecea7fe00cffded1bf454b8a6d7dd2
Author: Andre Przywara <andre.przywara@arm.com>
Date: Thu Oct 19 13:48:37 2017 +0100
ARM: vGIC: fix nr_irq definition
The global variable "nr_irqs" is used for x86 and some common Xen code.
To make the latter work easily for ARM, it was #defined to NR_IRQS.
This not only violated the common habit of capitalizing macros, but
also caused issues if one wanted to use a rather innocent "nr_irqs" as
a local variable name or as a function parameter.
Drop the optimization and make nr_irqs a normal variable for ARM also.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
commit 2e9b1c655f060b5c4e68bc8499f02253babe1bbc
Author: Andre Przywara <andre.przywara@arm.com>
Date: Thu Oct 19 13:48:36 2017 +0100
ARM: remove unneeded gic.h inclusions
gic.h is supposed to hold defines and prototypes for the hardware side
of the GIC interrupt controller. A lot of parts in Xen should not be
bothered with that, as they either only care about the VGIC or use
more generic interfaces.
Remove unneeded inclusions of gic.h from files where they are actually
not needed.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
commit c05aa4afac64ea687c1a2bf9277ba6552809495b
Author: Julien Grall <julien.grall@linaro.org>
Date: Wed Nov 29 17:57:32 2017 +0000
xen/arm: bootfdt: Use proper default for #address-cells and #size-cells
Per the device-tree specific [1], when the property #address-cells
and #size-cells are not present, the default value should be resp. 1
and 2.
[1] https://www.devicetree.org/downloads/devicetree-specification-v0.1-20160524.pdf
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(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] only message in thread
only message in thread, other threads:[~2017-12-14 2:40 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-14 2:40 [xen-unstable-smoke test] 117106: trouble: blocked/broken osstest service owner
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.