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
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 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 saver
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
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 ; xen-devel@lis
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
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
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 Juerg
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
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
test-amd64-amd64-xl-qemut-debian
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 "agre
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 ; xen-devel@lists.xenproject.o
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
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
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 toolsta
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 mapping)
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
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 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 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
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 mem
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 ta
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 succee
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 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
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.
> >
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
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
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 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):
test-arm64-arm6
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 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
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 applies
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 (backend)
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
>
> 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 pe
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 | 7
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 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 Zhe
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
> ---
> x
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.
>
> Si
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
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 statical
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 repo
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
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
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, a
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 qemu-
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
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, whic
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
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 com
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 saver
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 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 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 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
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
On Thu, Apr 14, 2022 at 10:19:31PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
Various updates is a big indicator that the patch should be split
further. Please do one change at a time, and fold updates to the
previous patches in the series into those patches instead of fixin
On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote:
> This makes sense overall. Considering that the swiotlb-xen case and the
> virtio case are mutually exclusive, I would write it like this:
Curious question: Why can't the same grant scheme also be used for
non-virtio devices? I
60 matches
Mail list logo
