[xen-4.13-testing bisection] complete test-xtf-amd64-amd64-4

2020-09-26 Thread osstest service owner
branch xen-4.13-testing xenbranch xen-4.13-testing job test-xtf-amd64-amd64-4 testid xtf/test-pv64-xsa-221 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu

[libvirt test] 154909: trouble: blocked/broken

2020-09-26 Thread osstest service owner
flight 154909 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/154909/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-pvops

[xen-4.10-testing test] 154913: trouble: blocked/broken

2020-09-26 Thread osstest service owner
flight 154913 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154913/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken

Re: [PATCH 0/4] xen/arm: Unbreak ACPI

2020-09-26 Thread Elliott Mitchell
On Sat, Sep 26, 2020 at 09:55:38PM +0100, Julien Grall wrote: > Xen on ARM has been broken for quite a while on ACPI systems. This > series aims to fix it. > > Unfortunately I don't have a system with ACPI v6.0 or later (QEMU seems > to only support 5.1). So I did only some light testing. > > I

[PATCH 1/4] xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()

2020-09-26 Thread Julien Grall
From: Julien Grall The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic while the __acpi_os_{un,}map_memory() are meant to be arch-specific. Currently, the former are still containing x86 specific code. To avoid this rather strange split, the generic helpers are reworked so

[PATCH 4/4] xen/arm: Introduce fw_unreserved_regions() and use it

2020-09-26 Thread Julien Grall
From: Julien Grall Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree later on in the boot", the device-tree will not be kept mapped when using ACPI. However, a few places are calling dt_unreserved_regions() which expects a valid DT. This will lead to a crash. As the DT should

[PATCH 3/4] xen/arm: Check if the platform is not using ACPI before initializing Dom0less

2020-09-26 Thread Julien Grall
From: Julien Grall Dom0less requires a device-tree. However, since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree later on in the boot", the device-tree will not get unflatten when using ACPI. This will lead to a crash during boot. Given the complexity to setup dom0less with

[PATCH 0/4] xen/arm: Unbreak ACPI

2020-09-26 Thread Julien Grall
From: Julien Grall Hi all, Xen on ARM has been broken for quite a while on ACPI systems. This series aims to fix it. Unfortunately I don't have a system with ACPI v6.0 or later (QEMU seems to only support 5.1). So I did only some light testing. I have only build tested the x86 side so far.

[PATCH 2/4] xen/arm: acpi: The fixmap area should always be cleared during failure/unmap

2020-09-26 Thread Julien Grall
From: Julien Grall Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in {set, clear}_fixmap()" enforced that each set_fixmap() should be paired with a clear_fixmap(). Any failure to follow the model would result to a platform crash. Unfortunately, the use of fixmap in the ACPI

[xen-4.12-testing test] 154758: regressions - trouble: broken/fail/pass

2020-09-26 Thread osstest service owner
flight 154758 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154758/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm broken test-amd64-i386-freebsd10-amd64

[xen-4.10-testing test] 154876: trouble: blocked/broken

2020-09-26 Thread osstest service owner
flight 154876 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154876/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken

[libvirt test] 154771: regressions - trouble: blocked/broken/fail/pass

2020-09-26 Thread osstest service owner
flight 154771 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/154771/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt broken build-i386-libvirt4

Re: [PATCH V1 09/16] arm/ioreq: Introduce arch specific bits for IOREQ/DM features

2020-09-26 Thread Oleksandr
On 26.09.20 16:21, Julien Grall wrote: Hi Oleksandr, Hi Julien. On 24/09/2020 19:22, Oleksandr wrote: On 24.09.20 20:25, Julien Grall wrote: On 23/09/2020 21:16, Oleksandr wrote: On 23.09.20 21:03, Julien Grall wrote: On 10/09/2020 21:22, Oleksandr Tyshchenko wrote: From: Oleksandr

Re: [PATCH V1 12/16] xen/dm: Introduce xendevicemodel_set_irq_level DM op

2020-09-26 Thread Oleksandr
On 26.09.20 16:50, Julien Grall wrote: (+ Paul and Andre) Hi, Hi Julien Adding Paul as the author of DMOP and Andre as this is GIC related. On 10/09/2020 21:22, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Looking at the PoC I shared with you, this code was originally

Re: [PATCH V1 12/16] xen/dm: Introduce xendevicemodel_set_irq_level DM op

2020-09-26 Thread Julien Grall
(+ Paul and Andre) Hi, Adding Paul as the author of DMOP and Andre as this is GIC related. On 10/09/2020 21:22, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Looking at the PoC I shared with you, this code was originally written by me. This patch adds ability to the device

Re: [PATCH V1 09/16] arm/ioreq: Introduce arch specific bits for IOREQ/DM features

2020-09-26 Thread Julien Grall
Hi Oleksandr, On 24/09/2020 19:22, Oleksandr wrote: On 24.09.20 20:25, Julien Grall wrote: On 23/09/2020 21:16, Oleksandr wrote: On 23.09.20 21:03, Julien Grall wrote: On 10/09/2020 21:22, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Could you please clarify how this patch could

Re: [PATCH V1 09/16] arm/ioreq: Introduce arch specific bits for IOREQ/DM features

2020-09-26 Thread Oleksandr
On 26.09.20 16:12, Julien Grall wrote: Hi, Hi Julien. On 24/09/2020 19:02, Oleksandr wrote: On 24.09.20 19:02, Oleksandr wrote: On 24.09.20 14:08, Jan Beulich wrote: On 23.09.2020 22:16, Oleksandr wrote: On 23.09.20 21:03, Julien Grall wrote: On 10/09/2020 21:22, Oleksandr

Re: [PATCH V1 09/16] arm/ioreq: Introduce arch specific bits for IOREQ/DM features

2020-09-26 Thread Julien Grall
Hi, On 24/09/2020 19:02, Oleksandr wrote: On 24.09.20 19:02, Oleksandr wrote: On 24.09.20 14:08, Jan Beulich wrote: On 23.09.2020 22:16, Oleksandr wrote: On 23.09.20 21:03, Julien Grall wrote: On 10/09/2020 21:22, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko @@ -91,6 +108,28 @@

Re: [PATCH v4 2/4] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

2020-09-26 Thread Julien Grall
Hi Andrew, On 22/09/2020 19:56, Andrew Cooper wrote: On 22/09/2020 19:20, Julien Grall wrote: +   #endif /* __ASM_DOMAIN_H__ */     /* diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 5c5e55ebcb76..7564df5e8374 100644 --- a/xen/include/public/domctl.h +++

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

2020-09-26 Thread Vasily Gorbik
On Fri, Sep 25, 2020 at 09:54:52AM -0400, Qian Cai wrote: > On Wed, 2020-08-26 at 13:17 +0200, Thomas Gleixner wrote: > > From: Thomas Gleixner > > > > The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture > > requires them or not. Architectures which are fully utilizing

[ovmf test] 154753: trouble: broken/pass

2020-09-26 Thread osstest service owner
flight 154753 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/154753/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 broken

[xen-4.11-testing test] 154740: regressions - FAIL

2020-09-26 Thread osstest service owner
flight 154740 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154740/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs.

[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-1

2020-09-26 Thread osstest service owner
branch xen-4.14-testing xenbranch xen-4.14-testing job test-xtf-amd64-amd64-1 testid xtf/test-pv64-xsa-221 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu

[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-2

2020-09-26 Thread osstest service owner
branch xen-4.14-testing xenbranch xen-4.14-testing job test-xtf-amd64-amd64-2 testid xtf/test-pv64-xsa-221 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu

[xen-4.14-testing bisection] complete test-xtf-amd64-amd64-2

2020-09-26 Thread osstest service owner
branch xen-4.14-testing xenbranch xen-4.14-testing job test-xtf-amd64-amd64-2 testid xtf/test-hvm64-xsa-221 Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu

[xen-4.10-testing test] 154844: trouble: blocked/broken

2020-09-26 Thread osstest service owner
flight 154844 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154844/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken

[linux-5.4 test] 154718: tolerable FAIL - PUSHED

2020-09-26 Thread osstest service owner
flight 154718 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/154718/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-examine4 memdisk-try-append fail in 154644 pass in 154718 test-armhf-armhf-xl-rtds 16

Re: remove alloc_vm_area v2

2020-09-26 Thread Christoph Hellwig
On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote: > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > > > this series removes alloc_vm_area, which was left over from the big > > vmalloc interface rework. It is a rather arkane interface, basicaly > > the equivalent of