flight 142749 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
test-amd64-amd64-xl-qemuu
flight 142736 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which are faili
On 15.10.19 05:49, Stefano Stabellini wrote:
There is no need to have a special dom0 case to convert the pgtable
virtual address into a physical address. The virt_to_maddr function can
work both in the dom0 case and the domU case.
This is more than a cleanup: when Xen is loaded at addresses lowe
There is no need to have a special dom0 case to convert the pgtable
virtual address into a physical address. The virt_to_maddr function can
work both in the dom0 case and the domU case.
This is more than a cleanup: when Xen is loaded at addresses lower than
2MB on arm32 phys_offset might not hold
> On Oct 11, 2019, at 07:11, Lars Kurth wrote:
>
> On 11/10/2019, 02:24, "Stefano Stabellini" wrote:
>
>>On Thu, 10 Oct 2019, Lars Kurth wrote:
>> * Would we ever include API docs generated from GPLv2 code? E.g. for safety
>> use-cases?
>> @Stefano, @Artem: I guess this one is for you.
>
On Oct 11, 2019, at 07:11, Lars Kurth wrote:
>
> On 11/10/2019, 02:24, "Stefano Stabellini" wrote:
>
>>On Thu, 10 Oct 2019, Lars Kurth wrote:
>> * Would we ever include API docs generated from GPLv2 code? E.g. for safety
>> use-cases?
>> @Stefano, @Artem: I guess this one is for you.
>>
flight 142735 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel broken
test-amd64-i386-xl-qemuu-debianhvm
On Mon, Oct 14, 2019 at 05:51:04PM +0100, Ian Jackson wrote:
> ---
> v4: Fix trailing whitespace
> No longer change "unknown" to "unspecified".
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 64bed30bce..7e220d0c20 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs
On 10/14/19 10:22 AM, Philippe Mathieu-Daudé wrote:
> This is a follow-up of Markus's cleanup series:
> Tame a few "touch this, recompile the world"
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg635748.html
>
> This part is mostly restricted to X86, but since some file from the
> Alpha
On 10/14/19 10:22 AM, Philippe Mathieu-Daudé wrote:
> The ICH9 chipset is not X86/PC specific.
>
> These files don't use anything declared by the "hw/i386/pc.h"
> or "hw/i386/ioapic.h" headers. Remove them.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: John Snow
> ---
> hw/acpi/ic
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl:
Move shadow_memkb and iommu_memkb defaulting into libxl"):
> So maybe libxl__domain_build_info_setdefault() should also set a value
> to iommu_memkb as it does for shadow_memkb? At least, set iommu_memkb=0
> if still the
On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> Overhaul passthrough setting logic"):
> > On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> > >
> > > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl:
Move shadow_memkb and iommu_memkb defaulting into libxl"):
> There's probably something else that is needed to be done for user of
> the pre-4.13 API. If they call libxl_domain_need_memory_0x041200, there
> is nothing tha
Here's what I hope is the final version...
From b60195e857d3699eaa55d9174a69bf91902cddb5 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Mon, 7 Oct 2019 17:59:15 +0100
Subject: [XEN PATCH v4 for-4.13 10/10] libxl/xl: Overhaul passthrough setting
logic
LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" i
On Fri, Oct 11, 2019 at 05:55:44PM +0100, Ian Jackson wrote:
> For callers which call libxl_domain_need_memory, and request an old
> pre-4.13 libxl API, and which leave one of these memkb settings unset,
> we take special measures to preserve the old behaviour.
>
> This means that they don't get t
Wei Liu writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul
passthrough setting logic"):
> On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> > Bikeshed colour Paul Juergen George Ian Anthony Wei #already
> >
> > unknown ? ? -1+2?
flight 142748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142748/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, Oct 14, 2019 at 05:09:24PM +0100, Ian Jackson wrote:
> Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> Overhaul passthrough setting logic"):
> > On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> > >
> > > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v3 10/10] libxl/xl:
Overhaul passthrough setting logic"):
> On Fri, Oct 11, 2019 at 05:55:49PM +0100, Ian Jackson wrote:
> > LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
>
> I guess that's now LIBXL_PASSTHROUGH_UNSP
Paul Durrant writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
Overhaul passthrough setting logic"):
> On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
> >
> > Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> > Overhaul passthrough setting logic"):
> > >
On Fri, Oct 11, 2019 at 05:55:49PM +0100, Ian Jackson wrote:
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
I guess that's now LIBXL_PASSTHROUGH_UNSPECIFIED.
> version of this code) is doing double duty. We actually need all of
> the following to be specificable:
> * defa
flight 142723 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
140282
test-amd64-i38
On Thu, Oct 10, 2019 at 06:13:43PM +0200, Sander Eikelenboom wrote:
>On 01/10/2019 12:35, Anthony PERARD wrote:
>> Rewrite of the commit message:
>>
>> Before the problematic commit, libxl used to ignore error when
>> destroying (force == true) a passthrough device, especially error that
>> happen
flight 142722 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142722/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 19 leak-check/check fail in 142683 pass in 142722
test-armhf-armhf-xl-rtds 12
On 10/9/19 6:35 AM, Jan Beulich wrote:
> On 09.10.2019 14:52, Roger Pau Monne wrote:
>> When using posted interrupts and the guest migrates MSI from vCPUs Xen
>> needs to flush any pending PIRR vectors on the previous vCPU, or else
>> those vectors could get wrongly injected at a later point when t
Various headers are not required by hw/i386/pc.h:
- "qemu/range.h"
- "qemu/bitmap.h"
- "qemu/module.h"
- "exec/memory.h"
- "hw/pci/pci.h"
- "hw/mem/pc-dimm.h"
- "hw/mem/nvdimm.h"
- "net/net.h"
Remove them.
Add 3 headers that were missing:
- "hw/hotplug.h"
PCMachineState::acpi_dev i
Only q35.c requires declarations from "hw/i386/pc.h", move it there.
Remove all the includes not used by "q35.h".
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/q35.c | 1 +
include/hw/pci-host/q35.h | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/hw/pci
All this files use methods/definitions declared in the NVDIMM
device header. Include it.
This fixes (when modifying unrelated headers):
hw/i386/acpi-build.c:2733:9: error: implicit declaration of function
'nvdimm_build_acpi' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
n
Both ich9.c and piix4.c use methods/definitions declared in the
NVDIMM device header. Include it.
This fixes (when modifying unrelated headers):
hw/acpi/ich9.c:507:46: error: use of undeclared identifier 'TYPE_NVDIMM'
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
hw/pci-host/piix.c calls various functions from the Range API.
Include "qemu/range.h" which declares them.
This fixes (when modifying unrelated headers):
hw/pci-host/i440fx.c:54:11: error: field has incomplete type 'Range' (aka
'struct Range')
Range pci_hole;
^
include/qemu/
hw/i2c/smbus_ich9.c calls range_covers_byte(). Include "qemu/range.h"
which declares it.
This fixes (when modifying unrelated headers):
hw/i2c/smbus_ich9.c:66:9: error: implicit declaration of function
'range_covers_byte' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (ra
The MCHPCIState structure uses the Range type which is declared in
"qemu/range.h". Include it.
This fixes (when modifying unrelated headers):
In file included from hw/pci-host/q35.c:32:
include/hw/pci-host/q35.h:57:11: error: field has incomplete type 'Range'
(aka 'struct Range')
Range
On Mon, 14 Oct 2019 at 15:27, Philippe Mathieu-Daudé wrote:
>
> xen_pt_load_rom.c does not use any of these includes, remove them.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Paul Durrant
> ---
> hw/xen/xen_pt_load_rom.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/h
hw/timer/hpet.c calls address_space_stl_le() declared in
"exec/address-spaces.h". Include it.
This fixes (when modifying unrelated headers):
hw/timer/hpet.c:210:31: error: use of undeclared identifier
'address_space_memory'
address_space_stl_le(&address_space_memory, timer->fsb >> 32
hw/acpi/cpu_hotplug.c calls pci_address_space_io(). Include
"hw/pci/pci.h" which declares it.
This fixes (when modifying unrelated headers):
hw/acpi/cpu_hotplug.c:103:28: error: implicit declaration of function
'pci_address_space_io' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
hw/hppa/machine.c uses NICInfo variables which are declared in
"net/net.h". Include it.
This fixes (when modifying unrelated headers):
hw/hppa/machine.c:126:21: error: use of undeclared identifier 'nb_nics'
for (i = 0; i < nb_nics; i++) {
^
hw/hppa/machine.c:127:30
hw/alpha/dp264.c uses NICInfo variables which are declared in
"net/net.h". Include it.
This fixes (when modifying unrelated headers):
hw/alpha/dp264.c:89:21: error: use of undeclared identifier 'nb_nics'
for (i = 0; i < nb_nics; i++) {
^
hw/alpha/dp264.c:90:30: err
alpha_sys.h does not use anything from the "hw/ide.h" header.
Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/alpha/alpha_sys.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/alpha/alpha_sys.h b/hw/alpha/alpha_sys.h
index 4e127a6de8..9991535c0d 100644
--- a/hw/alpha/alpha_sys.h
++
intel_iommu.h does not use any of these includes, remove them.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/intel_iommu.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
index 66b931e526..a1c4afcda5 100644
--- a/in
xen_pt_load_rom.c does not use any of these includes, remove them.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/xen/xen_pt_load_rom.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 307a5c93e2..a50a80837e 100644
--- a/hw/xen/xen_pt
flight 142739 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
The USB models related to storage don't need anything from
"ui/console.h". Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/usb/dev-storage.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c
index 8545193488..a2ff52d3e5 100644
--- a/hw/usb/dev
The timer models don't need anything from "ui/console.h".
Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/timer/hpet.c | 1 -
hw/timer/twl92230.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
index 1ddae4e7d7..4772cccfe3 100644
--- a/hw/timer/
The "ioapic_internal.h" does not use anything from
"hw/i386/ioapic.h", remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ioapic_internal.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/hw/i386/ioapic_internal.h
b/include/hw/i386/ioapic_internal.h
index d46c87c510
The keyboard controller model don't need anything from
"hw/i386/pc.h". Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/input/pckbd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index f0acfd86f7..2f09f780ba 100644
--- a/hw/input/pckbd.c
+++ b/hw/
The ICH9 chipset is not X86/PC specific.
These files don't use anything declared by the "hw/i386/pc.h"
or "hw/i386/ioapic.h" headers. Remove them.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/ich9.c | 1 -
hw/isa/lpc_ich9.c | 2 --
include/hw/i386/ich9.h | 1 -
3 files changed
vl.c calls machine_usb() declared in "hw/boards.h". Include it.
This fixes (when modifying unrelated headers):
vl.c:1283:10: error: implicit declaration of function 'machine_usb' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (!machine_usb(current_machine)) {
^
This is a follow-up of Markus's cleanup series:
Tame a few "touch this, recompile the world"
https://www.mail-archive.com/qemu-devel@nongnu.org/msg635748.html
This part is mostly restricted to X86, but since some file from the
Alpha/PA-RISC machines include "hw/i386/pc.h" I had to fix them
too.
E
flight 142733 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
test-amd64-amd64-xl-qemuu
On 10/14/19 3:19 AM, Vladimir Sementsov-Ogievskiy wrote:
+|
+- error_propagate(errp, local_err);
+)
+ ...>
+ }
+
It looks like once this script is run, error_propagate_prepend() will have no
clients.
No, it still have a bit, when working with error_copy, and/or moving errors
from/to
flight 142742 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142742/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 11.10.19 17:02, Andrew Cooper wrote:
The virtual address of the base of the IOMMU's regsters is not useful for
diagnostic purposes, and is quite voluminous. The PCI coordinates is by far
the most useful piece of identifying information.
Signed-off-by: Andrew Cooper
Release-acked-by: Juerg
On 12.10.19 20:18, Andrew Cooper wrote:
The xen-ucode utility is new with the late loading improvements in 4.13.
Update the documentation suitably.
Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
X
On 14.10.19 11:02, Wei Liu wrote:
Cc Juergen.
Looks pretty harmless for 4.13.
Yes.
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, Oct 11, 2019 at 05:55:48PM +0100, Ian Jackson wrote:
> We need this before we start to figure out the passthrough mode.
>
> I have checked that nothing in libxl__domain_create_info_setdefault
> nor the two implementations of ..._arch_... accesses anything else,
> other than (i) the domain
On Fri, Oct 11, 2019 at 05:55:44PM +0100, Ian Jackson wrote:
> Defaulting is supposed to be done by libxl. So these calculations
> should be here in libxl. libxl__domain_config_setdefault has all the
> necessary information including the values of max_memkb and max_vcpus.
>
> The overall functio
Hi all,
Xen 4.13 rc1 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.13.0-rc1
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.13.0-rc1/xen-4.13.0-rc1.tar.gz
And the signature is at:
https://downloads.xenproject.org
On Mon, Oct 14, 2019 at 12:00:25PM +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-10-14 at 16:28 +0800, Shawn Guo wrote:
> > On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote:
> > > qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
> > > which acts a
Committers,
The commit moratorium is lifted, please commit patches that are already
Release-acked.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, 14 Oct 2019 at 10:09, Juergen Gross wrote:
>
> Do some cleanup of the netback init and deinit code:
>
> - add an omnipotent queue deinit function usable from
> xenvif_disconnect_data() and the error path of xenvif_connect_data()
> - only install the irq handlers after initializing all re
On Mon, 14 Oct 2019 at 10:09, Juergen Gross wrote:
>
> xenvif_connect_data() calls module_put() in case of error. This is
> wrong as there is no related module_get().
>
> Remove the superfluous module_put().
>
> Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif
> is shut
On Mon, 2019-10-14 at 16:28 +0800, Shawn Guo wrote:
> On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote:
> > qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
> > which acts a bus in this regard. So far it maked all devices as
> > dma-coherent but no dma-
On Fri, Oct 11, 2019 at 1:53 PM Jiri Slaby wrote:
>
> Introduce new C macros for annotations of functions and data in
> assembly. There is a long-standing mess in macros like ENTRY, END,
> ENDPROC and similar. They are used in different manners and sometimes
> incorrectly.
>
> So introduce macros
Hi Ian,
On 11/10/2019 16:14, Ian Jackson wrote:
Oleksandr Grytsov writes ("[PATCH v1] Reset iomem's gfn to LIBXL_INVALID_GFN on
reboot"):
During domain reboot its configuration is partially reused
to re-create a new domain, but iomem's GFN field for the
iomem is only restored for those memory
12.10.2019 5:10, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/
>
>
>
> Hi,
>
> This series failed the docker-quick@centos7 build test. Please find the
> testing commands and
> their output below. If you have Docker insta
12.10.2019 5:52, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Subject: [RFC v5 000/126] error: auto prop
xenvif_connect_data() calls module_put() in case of error. This is
wrong as there is no related module_get().
Remove the superfluous module_put().
Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif is
shut down")
Cc: # 3.12
Signed-off-by: Juergen Gross
---
drivers/net
Do some cleanup of the netback init and deinit code:
- add an omnipotent queue deinit function usable from
xenvif_disconnect_data() and the error path of xenvif_connect_data()
- only install the irq handlers after initializing all relevant items
(especially the kthreads related to the queue)
-
One bugfix (patch 1) I stumbled over while doing a cleanup (patch 2)
of the xen-netback init/deinit code.
Juergen Gross (2):
xen/netback: fix error path of xenvif_connect_data()
xen/netback: cleanup init and deinit code
drivers/net/xen-netback/interface.c | 115 +-
flight 142711 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142648 REGR.
vs. 139698
Tests which
Cc Juergen.
Looks pretty harmless for 4.13.
On Mon, 14 Oct 2019 at 05:23, Samuel Thibault
wrote:
>
> Olaf Hering, le dim. 13 oct. 2019 18:50:32 +0200, a ecrit:
> > Am Sun, 13 Oct 2019 18:21:27 +0200
> > schrieb Samuel Thibault :
> >
> > > > > cked-by: Daniel De Graaf
> > >
> > > Note that you m
11.10.2019 20:02, Eric Blake wrote:
> On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> At the request of Markus: full version of errp propagation. Let's look
>> at it. Cover as much as possible, except inserting macro invocation
>> where it's not necessary.
>>
>> It's huge
flight 142709 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On Tue, Sep 24, 2019 at 08:12:39PM +0200, Nicolas Saenz Julienne wrote:
> The bus behind the board's PCIe core has DMA addressing limitations. Add
> an empty 'dma-ranges' property on all PCIe bus descriptions to inform
> the OF core that a translation is due further down the line.
>
> Signed-off-b
On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote:
> qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
> which acts a bus in this regard. So far it maked all devices as
> dma-coherent but no dma-ranges recommendation is made.
>
> The truth is that the un
11.10.2019 20:12, Eric Blake wrote:
> On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> ---
>>
>
>> scripts/coccinelle/auto-propagated-errp.cocci | 118 ++
>> 1 file changed, 118 insertions(+)
>> create mode 100644 scr
On Fri, 11 Oct 2019 at 17:34, Ian Jackson wrote:
>
> Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl:
> Overhaul passthrough setting logic"):
> > On 11.10.19 15:31, Ian Jackson wrote:
> > > I do not have a strong opinion about this. I would be happy with
> > > "auto" (o
flight 142717 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
test-amd64-amd64-xl-qemuu
78 matches
Mail list logo
