I have a reproducible Xen hypervisor crash (tried 4.15 and 4.16) when
using gdbsx to perform debugging on a guest.
steps to reproduce:
xen host system built without CONFIG_GDBSX configured
start a linux guest
attach gdbsx to the guest (e.g. gdbsx -a {domid} 64
on a remote system, set up a
flight 169446 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169446/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169445 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169443 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169441 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169434 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169434/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169409
test-armhf-armhf-libvirt 16
From: Stefano Stabellini
When the length of the string is zero of_property_read_string should
return -ENODATA according to the description of the function.
However, of_property_read_string doesn't check prop->length. If
prop->length is zero, return -ENODATA.
Without this patch the following
flight 169440 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu container. The minimal test simply boots Xen
(built from previous build stages) and Dom0.
The test needs a working kernel and minimal initrd for dom0. Instead of
building our own kernel and initrd,
From: Stefano Stabellini
Add qemu-system-arm to the existing test-artifacts qemu container (which
doesn't get build for every iteration but only updated once in a while.)
With qemu-system-arm available, we'll be able to run ARM32 tests.
This patch also bumps the QEMU version to v6.0.0 for both
Hi all,
This small series adds a simple Xen + Dom0 boot arm32 test to gitlab-ci
using QEMU, similar to the existing tests for arm64 and x86.
Cheers,
Stefano
Stefano Stabellini (2):
gitlab-ci: add qemu-system-arm to the existing tests-artifacts container
gitlab-ci: add an ARM32
On Wed, 23 Mar 2022, Michal Orzel wrote:
> Hi Stefano,
Hi Michal,
I addressed both points below. Sorry for taking so long but the CI-loop
was blocked on ARM. Now it is running again.
> On 22.03.2022 21:38, Stefano Stabellini wrote:
> > Add a minimal ARM32 smoke test based on qemu-system-arm,
flight 169439 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi,
On Fri, 15 Apr 2022 at 22:19, Stefano Stabellini
wrote:
> On Fri, 15 Apr 2022, Penny Zheng wrote:
> > > Hi Stefano,
> > >
> > > On 21/03/2022 20:03, Stefano Stabellini wrote:
> > > > On Mon, 21 Mar 2022, Jan Beulich wrote:
> > > >> On 18.03.2022 22:50, Stefano Stabellini wrote:
> > > >>> On
On Wed, 13 Apr 2022, Bertrand Marquis wrote:
> cppcheck can be used to check Xen code quality.
>
> To create a report do "make cppcheck" on a built tree adding any options
> you added during the process you used to build xen (like CROSS_COMPILE
> or XEN_TARGET_ARCH). This will generate an xml
Hi Penny,
Sorry for the formatting.
On Fri, 15 Apr 2022 at 09:53, Penny Zheng wrote:
> Hi jan
>
> > -
> > > +#ifdef CONFIG_STATIC_SHM
> > > +static void __init setup_shared_domain(void) {
> > > +/*
> > > + * Initialise our DOMID_SHARED domain.
> > > + * This domain owns
flight 169438 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, 14 Apr 2022, Michal Orzel wrote:
> DT_MATCH_TIMER stores the compatible timer ids and as such should be
> used in all the places where we need to refer to them. make_timer_node
> explicitly lists the same ids as the ones defined in DT_MATCH_TIMER so
> make use of this macro instead.
>
>
On Thu, 14 Apr 2022, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> The i.MX LPUART Documentation:
> https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
> Chatper 13.6 Low Power Universal Asynchronous Receiver/
> Transmitter (LPUART)
>
> Tested-by: Henry Wang
> Signed-off-by: Peng Fan
> ---
>
On Fri, 15 Apr 2022, Penny Zheng wrote:
> > Hi Stefano,
> >
> > On 21/03/2022 20:03, Stefano Stabellini wrote:
> > > On Mon, 21 Mar 2022, Jan Beulich wrote:
> > >> On 18.03.2022 22:50, Stefano Stabellini wrote:
> > >>> On Fri, 18 Mar 2022, Jan Beulich wrote:
> > On 11.03.2022 07:11, Penny
flight 169437 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Call xen_virtio_setup_dma_ops() only for Xen-aware virtio devices
> in Xen guests if restricted access to the guest memory is enabled.
>
> Signed-off-by: Oleksandr Tyshchenko
> ---
> include/xen/arm/xen-ops.h |
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> In the context of current patch do the following:
> 1. Update code to support virtio-mmio devices
> 2. Introduce struct xen_virtio_data and account passed virtio devices
>(using list) as we need to store some
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch introduces new helper and places it in new header.
> The helper's purpose is to assign any Xen specific DMA ops in
> a single place. For now, we deal with xen-swiotlb DMA ops only.
> The subsequent patch
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Introduce Xen specific binding for the virtio-mmio device to be used
> by Xen virtio support driver in a subsequent commit.
>
> This binding specifies the ID of Xen domain where the corresponding
> device
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Juergen Gross
>
> In order to support virtio in Xen guests add a config option enabling
> the user to specify whether in all Xen guests virtio should be able to
> access memory via Xen grant mappings only on the host side.
>
> This
flight 169436 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169436/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169435 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169426 linux-5.4 real [real]
flight 169433 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169426/
http://logs.test-lab.xenproject.org/osstest/logs/169433/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 169432 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169432/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169431 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Honestly, I would prefer this to be split so as to make it easier to
review if nothing else.
On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
wrote:
>
> SoC platforms often have multiple ways of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a
On Fri, 15 Apr 2022, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 01:39:23PM -0700, Stefano Stabellini wrote:
> > OK, now we know that the code path with Xen is correct and it is the
> > same code path taken (dma_alloc_direct) as when !CONFIG_XEN and !SMMU.
> > That is how it should be.
> >
flight 169430 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169429 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169423 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169423/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169261
Tests which did not
On 15.04.22 11:44, Michael S. Tsirkin wrote:
Hello Michael
On Thu, Apr 14, 2022 at 10:19:27PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
The purpose of this RFC patch series is to add support for restricting memory
access under Xen using specific
grant
On 14.04.22 22:43, H. Peter Anvin wrote:
Hello Peter
On April 14, 2022 12:19:29 PM PDT, Oleksandr Tyshchenko
wrote:
From: Juergen Gross
In order to support virtio in Xen guests add a config option enabling
the user to specify whether in all Xen guests virtio should be able to
access
flight 169428 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169427 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169425 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169424 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 15.04.22 12:07, Alex Bennée wrote:
Hello Alex
Oleksandr Tyshchenko writes:
Hello all.
[Sorry for the possible format issues]
I have an update regarding (valid) concern which has been also raised in
current thread which is the virtio backend's ability (when using
Xen foreign
Hi all,
I'm facing always the same problem (described below) trying to create a Xen
guest domain on rockpro64 (arm64).
I have successfully built uboot, xen (4.14.4) and dom0 linux kernel with
xen tool stack, these two last starting from buildroot (with linux kernel
version 5.15.33 and xen
flight 169422 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 15.04.22 10:41, Christoph Hellwig wrote:
Hello Christoph
I can only see three out of 6 patches on the linux-arm-kernel list,
which makes reviewing this impossible.
Oops, I will add linux-arm-kernel. I blindly followed what
get_maintainer.pl suggested for each patch plus added manually
Hi jan
> -Original Message-
> From: Jan Beulich
> Sent: Friday, March 18, 2022 4:53 PM
> To: Penny Zheng
> Cc: nd ; Penny Zheng
> ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Volodymyr Babchuk
> ; Andrew Cooper
> ; George Dunlap ;
> Wei Liu ;
Oleksandr Tyshchenko writes:
> Hello all.
>
> [Sorry for the possible format issues]
>
> I have an update regarding (valid) concern which has been also raised in
> current thread which is the virtio backend's ability (when using
> Xen foreign mapping) to map any guest pages without guest
flight 169412 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169412/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 8 reboot fail in 169383 pass in 169412
flight 169421 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169421/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, Apr 14, 2022 at 10:19:27PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Hello all.
>
> The purpose of this RFC patch series is to add support for restricting memory
> access under Xen using specific
> grant table based DMA ops layer. Patch series is based on
flight 169420 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169415 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169415/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Julien and Stefano
> -Original Message-
> From: Julien Grall
> Sent: Saturday, April 9, 2022 5:12 PM
> To: Stefano Stabellini ; Jan Beulich
>
> Cc: Penny Zheng ; nd ; Penny Zheng
> ; Bertrand Marquis
> ; Volodymyr Babchuk
> ; Andrew Cooper
> ; George Dunlap ;
> Wei Liu ;
flight 169419 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169409 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169409/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169403
test-armhf-armhf-libvirt 16
I can only see three out of 6 patches on the linux-arm-kernel list,
which makes reviewing this impossible. Also please Cc me directly
on any series doing crazy things with dma ops. Thanks!
flight 169418 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, Apr 14, 2022 at 01:39:23PM -0700, Stefano Stabellini wrote:
> OK, now we know that the code path with Xen is correct and it is the
> same code path taken (dma_alloc_direct) as when !CONFIG_XEN and !SMMU.
> That is how it should be.
>
> I cannot explain why dma_alloc_direct() would fail
flight 169417 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
60 matches
Mail list logo
