[linux-5.4 test] 153977: regressions - FAIL

flight 153977 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/153977/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152853 build-i386-xsm

[ovmf test] 153997: regressions - FAIL

flight 153997 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153997/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

Re: [PATCH v2 6/7] xen/balloon: try to merge system ram resources

On 08.09.20 22:10, David Hildenbrand wrote: Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton Cc: Michal Hocko Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefa

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

On 08.09.20 22:10, David Hildenbrand wrote: We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de Acked-by: Wei Liu Cc: And

[qemu-mainline test] 153971: regressions - FAIL

flight 153971 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153971/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-

[ovmf test] 153993: regressions - FAIL

flight 153993 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153993/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[xen-unstable bisection] complete test-xtf-amd64-amd64-1

branch xen-unstable xenbranch xen-unstable job test-xtf-amd64-amd64-1 testid leak-check/check Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.x

[ovmf test] 153990: regressions - FAIL

flight 153990 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153990/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[ovmf test] 153985: regressions - FAIL

flight 153985 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153985/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[xen-unstable bisection] complete test-xtf-amd64-amd64-1

branch xen-unstable xenbranch xen-unstable job test-xtf-amd64-amd64-1 testid xtf/test-pv64-selftest Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xen

Re: [PATCH] golang/xenlight: Move to an entirely external repo

> On Sep 8, 2020, at 6:03 PM, Nick Rosbrook wrote: > > On Fri, Sep 04, 2020 at 05:40:00PM +0100, George Dunlap wrote: >> Remove all go files and generation targets. >> >> Add a convenience macro to build the package from staging. This isn't >> really meant to be called directly; rather, it's

[linux-linus test] 153961: regressions - FAIL

flight 153961 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153961/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152332 build-amd64-xsm

[xen-unstable test] 153957: regressions - FAIL

flight 153957 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/153957/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 18 xtf/test-pv64-selftest fail REGR. vs. 152877 test-amd64-coresch

[ovmf test] 153981: regressions - FAIL

flight 153981 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153981/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[ovmf test] 153978: regressions - FAIL

flight 153978 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153978/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[ovmf test] 153974: regressions - FAIL

flight 153974 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153974/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[linux-5.4 test] 153951: regressions - FAIL

flight 153951 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/153951/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152853 build-i386-xsm

[ovmf test] 153968: regressions - FAIL

flight 153968 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[PATCH v2 7/7] hv_balloon: try to merge system ram resources

Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton Cc: Michal Hocko Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Wei Liu Cc: Pankaj Gupta

[PATCH v2 6/7] xen/balloon: try to merge system ram resources

Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton Cc: Michal Hocko Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: Roger Pau Monné Cc: Julien

[PATCH v2 4/7] mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System RAM resources

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed

[PATCH v2 5/7] virtio-mem: try to merge system ram resources

virtio-mem adds memory in memory block granularity, to be able to remove it in the same granularity again later, and to grow slowly on demand. This, however, results in quite a lot of resources when adding a lot of memory. Resources are effectively stored in a list-based tree. Having a lot of resou

[PATCH v2 0/7] mm/memory_hotplug: selective merging of system ram resources

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed

[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de Acked-by: Wei Liu Cc: Andrew Morton Cc: Michal Hocko Cc: Dan Williams

[PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail

Let's make sure splitting a resource on memory hotunplug will never fail. This will become more relevant once we merge selected System RAM resources - then, we'll trigger that case more often on memory hotunplug. In general, this function is already unlikely to fail. When we remove memory, we free

[PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is always set to 0 by hardware. This is far from beautiful (and confusing), and the bit only applies to SYSRAM. So let's move it out of the bus-specific (PnP) defined bits. We'll add another SYSRAM specific bit soon. If we ever

Re: [PATCH v2] x86/pv: Fix assertions in svm_load_segs()

On 08/09/2020 16:36, Jan Beulich wrote: > On 08.09.2020 17:08, Andrew Cooper wrote: >> OSSTest has shown an assertion failure: >> http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log >> >> This is because we pass a non-NUL selector into svm_load_segs(),

[PATCH v4] hvmloader: indicate ACPI tables with "ACPI data" type in e820

Guest kernel does need to know in some cases where the tables are located to treat these regions properly. One example is kexec process where the first kernel needs to pass ACPI region locations to the second kernel which is now a requirement in Linux after 02a3e3cdb7f12 ("x86/boot: Parse SRAT tabl

[PATCH v2] x86/pv: Fix assertions in svm_load_segs()

OSSTest has shown an assertion failure: http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log This is because we pass a non-NUL selector into svm_load_segs(), which is something we must not do, as this path does not load the attributes/limit from the GDT

[xen-unstable-smoke test] 153963: tolerable all pass - PUSHED

flight 153963 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/153963/ 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

[qemu-mainline test] 153946: regressions - FAIL

flight 153946 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153946/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 build-i386

Re: [PATCH] lib: correct __moddi3() description

On 08/09/2020 13:54, Jan Beulich wrote: > The remainder of a division, when non-zero, is specified to always be of > the same sign as the dividend. Bring a comment in line with the code it > describes. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

[ovmf test] 153962: regressions - FAIL

flight 153962 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153962/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

Re: [PATCH] golang/xenlight: Move to an entirely external repo

On Fri, Sep 04, 2020 at 05:40:00PM +0100, George Dunlap wrote: > Remove all go files and generation targets. > > Add a convenience macro to build the package from staging. This isn't > really meant to be called directly; rather, it's meant to be called > from a corresponding build target inside t

Re: [PATCH v2 4/6] stubs: Split accelerator / hardware related stubs

On 9/8/20 5:55 PM, Philippe Mathieu-Daudé wrote: > Move hardware stubs unrelated from the accelerator to xen-hw-stub.c. > > Signed-off-by: Philippe Mathieu-Daudé > --- ... > Guest CPU Cores (HAXM) > - > diff --git a/stubs/meson.build b/stubs/meson.build > index e0b322bc282..

[PATCH v2 1/6] hw/i386/q35: Remove unreachable Xen code on Q35 machine

Xen accelerator requires specific changes to a machine to be able to use it. See for example the 'Xen PC' machine configure its PCI bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine declared. This code was probably added while introducing the Q35 machine, based on the existing PC mac

[PATCH v2 5/6] hw/xen: Split x86-specific declaration from generic hardware ones

xen_hvm_init() is restricted to the X86 architecture. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen-x86.h | 15 +++ include/hw/xen/xen.h | 2 -- hw/i386/pc_piix.c| 2 +- hw/i386/xen/xen-hvm.c| 1 + stubs/xen-hw-stub.c | 1 + 5 files changed, 18

[PATCH v2 0/6] hw/xen: Housekeeping

Hard to make an exciting cover of this series. Basically: - Make better separation between Xen accel and Xen hardware, - Move stuff around to restrict PCMachineState to hw/i386/. Since v1: - added missing include in stubs/xen-hw-stub.c - added missing 'exec/cpu-common.h' for ram_addr_t (Due to a

[PATCH v2 4/6] stubs: Split accelerator / hardware related stubs

Move hardware stubs unrelated from the accelerator to xen-hw-stub.c. Signed-off-by: Philippe Mathieu-Daudé --- accel/stubs/xen-stub.c | 41 +-- stubs/xen-hw-stub.c| 49 ++ MAINTAINERS| 1 + stubs/meson.build

[PATCH v2 6/6] typedefs: Restrict PCMachineState to 'hw/i386/pc.h'

The PCMachineState type is only used under hw/i386/. We don't need to forward-declare it for all architectures, restrict it to the X86 one. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/i386/pc.h| 4 ++-- include/qemu/typedefs.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)

[PATCH v2 3/6] sysemu/xen: Add missing 'exec/cpu-common.h' header for ram_addr_t type

As this header use the ram_addr_t type, it has to include "exec/cpu-common.h" to avoid odd errors such: include/sysemu/xen.h:35:44: error: unknown type name 'ram_addr_t'; did you mean 'in_addr_t'? 35 | static inline void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) |

[PATCH v2 2/6] hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()

xen_hvm_init() is only meanful to initialize a X86/PC machine, rename it as xen_hvm_init_pc(). Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen.h | 2 +- accel/stubs/xen-stub.c | 2 +- hw/i386/pc_piix.c | 6 +++--- hw/i386/xen/xen-hvm.c | 2 +- 4 files changed, 6 insertions(+

Re: [PATCH v4 2/5] x86/pv: allow reading FEATURE_CONTROL MSR

On 07.09.2020 12:31, Roger Pau Monne wrote: > Linux PV guests will attempt to read the FEATURE_CONTROL MSR, so move > the handling done in VMX code into guest_rdmsr as it can be shared > between PV and HVM guests that way. > > Note that there's a slight behavior change and attempting to read the >

Re: [PATCH v4 1/5] x86/svm: handle BU_CFG and BU_CFG2 with cases

On 07.09.2020 12:31, Roger Pau Monne wrote: > Move the special handling of reads to it's own switch case, and also > add support for BU_CFG2. On the write side ignore writes if the MSR is > readable, otherwise return a #GP. > > This is in preparation for changing the default MSR read/write > behav

Re: [PATCH v4] hvmloader: indicate ACPI tables with "ACPI data" type in e820

On 08.09.2020 17:41, Igor Druzhinin wrote: > Guest kernel does need to know in some cases where the tables are located > to treat these regions properly. One example is kexec process where > the first kernel needs to pass ACPI region locations to the second > kernel which is now a requirement in Li

Re: [PATCH v2] x86/pv: Fix assertions in svm_load_segs()

On 08.09.2020 17:08, Andrew Cooper wrote: > OSSTest has shown an assertion failure: > http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log > > This is because we pass a non-NUL selector into svm_load_segs(), which is > something we must not do, as this

[ovmf test] 153959: regressions - FAIL

flight 153959 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153959/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[linux-linus test] 153939: regressions - FAIL

flight 153939 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153939/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152332 build-amd64

Re: [PATCH] x86/pv: Drop assertions from svm_load_segs()

On 08/09/2020 11:36, Jan Beulich wrote: > On 08.09.2020 12:08, Andrew Cooper wrote: >> OSSTest has shown an assertion failure: >> http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log >> >> These assertions were never appropriate, as they rule out legal (

Re: [PATCH v3] hvmloader: indicate ACPI tables with "ACPI data" type in e820

On 08/09/2020 10:15, Jan Beulich wrote: > On 08.09.2020 01:42, Igor Druzhinin wrote: >> Changes in v3: >> - switched from NVS to regular "ACPI data" type by separating ACPI >> allocations >> into their own region >> - gave more information on particular kexec usecase that requires this change >

Re: [PATCH 4/5] hw/xen: Split x86-specific declaration from generic hardware ones

On 9/8/20 4:25 PM, Philippe Mathieu-Daudé wrote: > xen_hvm_init() is restricted to the X86 architecture. > > Signed-off-by: Philippe Mathieu-Daudé > --- > include/hw/xen/xen-x86.h | 15 +++ > include/hw/xen/xen.h | 2 -- > hw/i386/pc_piix.c| 2 +- > hw/i386/xen/xen-hvm.

[PATCH 4/5] hw/xen: Split x86-specific declaration from generic hardware ones

xen_hvm_init() is restricted to the X86 architecture. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen-x86.h | 15 +++ include/hw/xen/xen.h | 2 -- hw/i386/pc_piix.c| 2 +- hw/i386/xen/xen-hvm.c| 1 + 4 files changed, 17 insertions(+), 3 deletions(-) c

[PATCH 0/5] hw/xen: Housekeeping

Hard to make an exciting cover of this series. Basically: - Make better separation between Xen accel and Xen hardware, - Move stuff around to restrict PCMachineState to hw/i386/. Philippe Mathieu-Daudé (5): hw/i386/q35: Remove unreachable Xen code on Q35 machine hw/i386/xen: Rename X86/PC spe

[PATCH 2/5] hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()

xen_hvm_init() is only meanful to initialize a X86/PC machine, rename it as xen_hvm_init_pc(). Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen.h | 2 +- accel/stubs/xen-stub.c | 2 +- hw/i386/pc_piix.c | 6 +++--- hw/i386/xen/xen-hvm.c | 2 +- 4 files changed, 6 insertions(+

[PATCH 5/5] typedefs: Restrict PCMachineState to 'hw/i386/pc.h'

The PCMachineState type is only used under hw/i386/. We don't need to forward-declare it for all architectures, restrict it to the X86 one. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/i386/pc.h| 4 ++-- include/qemu/typedefs.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)

[ovmf test] 153953: regressions - FAIL

flight 153953 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153953/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

[PATCH 1/5] hw/i386/q35: Remove unreachable Xen code on Q35 machine

Xen accelerator requires specific changes to a machine to be able to use it. See for example the 'Xen PC' machine configure its PCI bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine declared. This code was probably added while introducing the Q35 machine, based on the existing PC mac

[PATCH 3/5] stubs: Split accelerator / hardware related stubs

Move hardware stubs unrelated from the accelerator to xen-hw-stub.c. Signed-off-by: Philippe Mathieu-Daudé --- accel/stubs/xen-stub.c | 41 +-- stubs/xen-hw-stub.c| 49 ++ MAINTAINERS| 1 + stubs/meson.build

[xen-unstable test] 153931: regressions - FAIL

flight 153931 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/153931/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-coresched-amd64-xl 12 guest-start fail REGR. vs. 152877 test-xtf-amd64-amd

Re: [PATCH 2/2] libxl: do not automatically force detach of block devices

On Thu, Sep 03, 2020 at 11:05:37AM +0100, Paul Durrant wrote: > From: Paul Durrant > > The manpage for 'xl' documents that guest co-operation is required for a (non- > forced) block-detach operation and that it may consequently fail. Currently, > however, the implementation of generic device remo

Re: [PATCH] Arm64: fix build with gcc 10

> On 8 Sep 2020, at 15:08, Jan Beulich wrote: > > On 08.09.2020 15:05, Bertrand Marquis wrote: >>> On 8 Sep 2020, at 13:53, Jan Beulich wrote: >>> >>> With gcc10 inlining is (no longer?) the default for certain atomics. >>> >>> Suggested-by: Julien Grall >>> Signed-off-by: Jan Beulich >>>

Re: [PATCH] Arm64: fix build with gcc 10

On 08.09.2020 15:03, Julien Grall wrote: > I would suggest: "xen/arm64: Force GCC to always inline generic atomics > helpers". > > On 08/09/2020 13:53, Jan Beulich wrote: >> With gcc10 inlining is (no longer?) the default for certain atomics. > > How about the following: > > "Recent versions of

[PATCH] x86/pv: Drop assertions from svm_load_segs()

OSSTest has shown an assertion failure: http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log These assertions were never appropriate, as they rule out legal (and, as it turns out, sensible perf-wise) inputs based on an expectation of how the sole caller

Re: [PATCH] Arm64: fix build with gcc 10

On 08.09.2020 15:05, Bertrand Marquis wrote: >> On 8 Sep 2020, at 13:53, Jan Beulich wrote: >> >> With gcc10 inlining is (no longer?) the default for certain atomics. >> >> Suggested-by: Julien Grall >> Signed-off-by: Jan Beulich >> --- a/xen/arch/arm/arch.mk >> +++ b/xen/arch/arm/arch.mk >> @@

Re: [PATCH 1/2] xl: implement documented --force option for block-detach

On Thu, Sep 03, 2020 at 11:05:36AM +0100, Paul Durrant wrote: > From: Paul Durrant > > The manpage for 'xl' documents an option to force a block device to be > released even if the domain to which it is attached does not co-operate. > This option, however, is not implemented. This patch implement

Re: [PATCH 0/2] fix 'xl block-detach'

On Tue, Sep 08, 2020 at 11:52:48AM +0100, Paul Durrant wrote: > Ping? Can I get a toolstack maintainer opinion on this? This series landed in my @xen.org inbox just fine but I haven't got around reviewing it. Wei.

[ovmf test] 153952: regressions - FAIL

flight 153952 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

Re: [patch V2 18/46] x86/msi: Consolidate MSI allocation

On Wed, Aug 26, 2020 at 01:16:46PM +0200, Thomas Gleixner wrote: [...] > --- a/drivers/pci/controller/pci-hyperv.c > +++ b/drivers/pci/controller/pci-hyperv.c > @@ -1534,7 +1534,7 @@ static struct irq_chip hv_msi_irq_chip = > static irq_hw_number_t hv_msi_domain_ops_get_hwirq(struct msi_domain_inf

Re: [patch V2 14/46] x86/ioapic: Consolidate IOAPIC allocation

On Wed, Aug 26, 2020 at 01:16:42PM +0200, Thomas Gleixner wrote: ... > --- a/drivers/iommu/hyperv-iommu.c > +++ b/drivers/iommu/hyperv-iommu.c > @@ -101,7 +101,7 @@ static int hyperv_irq_remapping_alloc(st >* in the chip_data and hyperv_irq_remapping_activate()/hyperv_ir_set_ >* aff

Re: [PATCH] Arm64: fix build with gcc 10

> On 8 Sep 2020, at 13:53, Jan Beulich wrote: > > With gcc10 inlining is (no longer?) the default for certain atomics. > > Suggested-by: Julien Grall > Signed-off-by: Jan Beulich > --- a/xen/arch/arm/arch.mk > +++ b/xen/arch/arm/arch.mk > @@ -12,6 +12,7 @@ CFLAGS-$(CONFIG_ARM_32) += -mcpu=co

Re: [PATCH] Arm64: fix build with gcc 10

Hi Jan, I would suggest: "xen/arm64: Force GCC to always inline generic atomics helpers". On 08/09/2020 13:53, Jan Beulich wrote: With gcc10 inlining is (no longer?) the default for certain atomics. How about the following: "Recent versions of GCC (at least GCC10) will not inline generic a

[PATCH] lib: correct __moddi3() description

The remainder of a division, when non-zero, is specified to always be of the same sign as the dividend. Bring a comment in line with the code it describes. Signed-off-by: Jan Beulich --- a/xen/common/lib.c +++ b/xen/common/lib.c @@ -390,7 +390,7 @@ u64 __umoddi3(u64 a, u64 b) * 11 % 5 = 1

[PATCH] Arm64: fix build with gcc 10

With gcc10 inlining is (no longer?) the default for certain atomics. Suggested-by: Julien Grall Signed-off-by: Jan Beulich --- a/xen/arch/arm/arch.mk +++ b/xen/arch/arm/arch.mk @@ -12,6 +12,7 @@ CFLAGS-$(CONFIG_ARM_32) += -mcpu=cortex- CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic CFLAGS-$(CONFI

[linux-5.4 test] 153926: regressions - FAIL

flight 153926 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/153926/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152853 build-i386-xsm

[ovmf test] 153948: regressions - FAIL

flight 153948 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153948/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

Re: [PATCH v3 1/4] x86/xen.lds.S: Work around binutils build id alignment bug

On 08.09.2020 11:30, Trammell Hudson wrote: > On Tuesday, September 8, 2020 11:04 AM, Jan Beulich wrote: >> [...] >> Personally I think this kind of a workaround patch is something >> distros ought to be fine to carry, if they care about the >> functionality and only until they get around to upgra

Re: [PATCH] Revert "x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()"

On Tue, Sep 08, 2020 at 07:47:09AM +0100, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 07 September 2020 18:09 > > To: xen-devel@lists.xenproject.org > > Cc: Roger Pau Monne ; Jan Beulich > > ; Andrew Cooper > > ; Wei Liu ; Paul Durrant > > > > Subject:

Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.

On Tue, Sep 08, 2020 at 12:02:53PM +0200, Gerd Hoffmann wrote: > > > > The comments I've found suggest very much not ... Or is that all very > > > > old stuff only that no one cares about anymore? > > > > > > I think these days it is possible to override dma_ops per device, which > > > in turn all

[ovmf test] 153943: regressions - FAIL

flight 153943 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153943/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

RE: [PATCH 0/2] fix 'xl block-detach'

Ping? Can I get a toolstack maintainer opinion on this? Thanks, Paul > -Original Message- > From: Paul Durrant > Sent: 03 September 2020 11:06 > To: xen-devel@lists.xenproject.org > Cc: Paul Durrant > Subject: [PATCH 0/2] fix 'xl block-detach' > > From: Paul Durrant > > This serie

Re: [PATCH v3] hvmloader: indicate ACPI tables with "ACPI data" type in e820

On 08.09.2020 12:44, Igor Druzhinin wrote: > On 08/09/2020 10:15, Jan Beulich wrote: >> On 08.09.2020 01:42, Igor Druzhinin wrote: >>> @@ -210,8 +223,8 @@ int build_e820_table(struct e820entry *e820, >>> { >>> uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT; >>> >>> -

[qemu-mainline test] 153922: regressions - FAIL

flight 153922 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153922/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-

Re: [PATCH] x86/pv: Drop assertions from svm_load_segs()

On 08.09.2020 12:08, Andrew Cooper wrote: > OSSTest has shown an assertion failure: > http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log > > These assertions were never appropriate, as they rule out legal (and, as it > turns out, sensible perf-wise) i

Re: [PATCH v1 5/5] hv_balloon: try to merge system ram resources

On 04.09.20 19:30, Wei Liu wrote: > On Fri, Aug 21, 2020 at 12:34:31PM +0200, David Hildenbrand wrote: >> Let's use the new mechanism to merge system ram resources below the >> root. We are the only one hotplugging system ram, e.g., DIMMs don't apply, >> so this is safe to be used. >> >> Cc: Andrew

Re: [PATCH v1 2/5] kernel/resource: merge_system_ram_resources() to merge resources after hotplug

On 31.08.20 11:35, Pankaj Gupta wrote: >> Some add_memory*() users add memory in small, contiguous memory blocks. >> Examples include virtio-mem, hyper-v balloon, and the XEN balloon. >> >> This can quickly result in a lot of memory resources, whereby the actual >> resource boundaries are not of in

Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.

> > > The comments I've found suggest very much not ... Or is that all very > > > old stuff only that no one cares about anymore? > > > > I think these days it is possible to override dma_ops per device, which > > in turn allows virtio to deal with the quirks without the rest of the > > kernel kno

Re: [PATCH v3 1/4] x86/xen.lds.S: Work around binutils build id alignment bug

On Tuesday, September 8, 2020 11:04 AM, Jan Beulich wrote: > [...] > Personally I think this kind of a workaround patch is something > distros ought to be fine to carry, if they care about the > functionality and only until they get around to upgrade their > binutils. But I'll be happy to hear dif

[ovmf test] 153938: regressions - FAIL

flight 153938 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153938/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

Re: [PATCH v3] hvmloader: indicate ACPI tables with "ACPI data" type in e820

On 08.09.2020 01:42, Igor Druzhinin wrote: > Changes in v3: > - switched from NVS to regular "ACPI data" type by separating ACPI allocations > into their own region > - gave more information on particular kexec usecase that requires this change Thanks a lot for doing both of these. > --- a/tool

Re: [PATCH v3 1/4] x86/xen.lds.S: Work around binutils build id alignment bug

On 07.09.2020 21:00, Trammell Hudson wrote: > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -156,6 +156,7 @@ SECTIONS > __note_gnu_build_id_end = .; >} :note :text > #elif defined(BUILD_ID_EFI) > + . = ALIGN(32); /* workaround binutils section overlap bug */ >DE

[libvirt test] 153928: regressions - FAIL

flight 153928 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/153928/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 151777 build-arm64-libvirt

Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.

On Tue, Sep 08, 2020 at 07:48:58AM +0200, Gerd Hoffmann wrote: > On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote: > > On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote: > > > > > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > > > call dma_max_mapping_size() to fig

Re: [PATCH] Revert "x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()"

On 07.09.2020 19:09, Roger Pau Monne wrote: > This reverts commit 81fd0d3ca4b2cd309403c6e8da662c325dd35750. > > Original commit only takes into account the APIC access page being a > 'special' page, but when running a PVH dom0 there are other pages that > also fulfill the 'special' page check but

[linux-linus test] 153912: regressions - FAIL

flight 153912 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153912/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152332 build-amd64

[ovmf test] 153936: regressions - FAIL

flight 153936 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/153936/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 152863 build-amd64-xsm

Re: [PATCH] EFI: Enable booting unified hypervisor/kernel/initrd images

On 07.09.2020 20:07, Julien Grall wrote: > > > On 07/09/2020 08:11, Jan Beulich wrote: >> On 04.09.2020 19:35, Julien Grall wrote: >>> On 04/09/2020 11:06, Trammell Hudson wrote: On Friday, September 4, 2020 5:29 AM, Julien Grall wrote: > On 28/08/2020 12:51, Trammell Hudson wrote: