[xtf test] 165349: all pass - PUSHED

flight 165349 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/165349/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 61e6f40b07d256bd62ae7b231a3eeecd49d0b15b baseline version: xtf 91d215a4ed1463ab14d1f6

Re: [PATCH v4 11/14] xen/arm: Enable the existing x86 virtual PCI support for ARM.

Hi Stefano, > On 5 Oct 2021, at 1:38 am, Stefano Stabellini wrote: > > On Mon, 4 Oct 2021, Rahul Singh wrote: >> The existing VPCI support available for X86 is adapted for Arm. >> When the device is added to XEN via the hyper call >> “PHYSDEVOP_pci_device_add”, VPCI handler for the config space

Re: [PATCH v4 00/14] PCI devices passthrough on Arm

Hi Stefano, > On 5 Oct 2021, at 1:57 am, Stefano Stabellini wrote: > > I committed patches #1, #4, #5 of this series > Thank you. Regards, Rahul

Re: [PATCH v4 03/14] xen/arm: Add PHYSDEVOP_pci_device_(*add/remove) support for ARM

On Tue, 5 Oct 2021, 01:46 Stefano Stabellini, wrote: > > Given that only ARM needs the !CONFIG_HAS_PCI stub, I would add it > directly to xen/arch/arm/physdev.c. Or just add an #ifdef directly > within do_physdev_op in xen/arch/arm/physdev.c. If we want to keep the stub, then it should be the g

[ovmf test] 165347: all pass - PUSHED

flight 165347 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/165347/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 4cc1458dbe004b1d70534caa55f475f6d19fe14a baseline version: ovmf 442e46d3b6c1931b54111

Re: xen-balloon thread using 100% of CPU, regression in 5.4.150

On 04.10.21 11:14, Marek Marczykowski-Górecki wrote: On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote: On 03.10.21 06:47, Marek Marczykowski-Górecki wrote: Hi, After updating a PVH domU to 5.4.150, I see xen-balloon thread using 100% CPU (one thread). This is a domain started with

Re: [PATCH v4 03/14] xen/arm: Add PHYSDEVOP_pci_device_(*add/remove) support for ARM

Hi Stefano, > On 5 Oct 2021, at 12:46 am, Stefano Stabellini wrote: > > On Mon, 4 Oct 2021, Rahul Singh wrote: >> Hardware domain is in charge of doing the PCI enumeration and will >> discover the PCI devices and then will communicate to XEN via hyper >> call PHYSDEVOP_pci_device_add(..) to add

[libvirt test] 165373: regressions - FAIL

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

[linux-5.4 test] 165346: regressions - FAIL

flight 165346 linux-5.4 real [real] flight 165375 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165346/ http://logs.test-lab.xenproject.org/osstest/logs/165375/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: t

Re: [PATCH v4 13/14] arm/libxl: Emulated PCI device tree node in libxl

Hi Stefano, > On 5 Oct 2021, at 1:38 am, Stefano Stabellini wrote: > > On Mon, 4 Oct 2021, Rahul Singh wrote: >> libxl will create an emulated PCI device tree node in the device tree to >> enable the guest OS to discover the virtual PCI during guest boot. >> Emulated PCI device tree node will on

[linux-linus test] 165348: regressions - FAIL

flight 165348 linux-linus real [real] flight 165376 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165348/ http://logs.test-lab.xenproject.org/osstest/logs/165376/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run

[PATCH] x86/spec-ctrl: Build with BRANCH_HARDEN lfences by default

Branch Harden is enabled by default at compile and boot time. Invert the code to compile with lfence by default and nop out in the non-default case. This has several advantages. It removes 3829 patch points (in the random build of Xen I have to hand) by default on boot, 70% (!) of the .altinstr_

[PATCH v2 0/9] proc/vmcore: sanitize access to virtio-mem memory

As so often with virtio-mem changes that mess with common MM infrastructure, this might be a good candiate to go via Andrew's tree. -- After removing /dev/kmem, sanitizing /proc/kcore and handling /dev/mem, this series tackles the last sane way how a VM could accidentially access logically unplug

[PATCH v2 1/9] x86/xen: update xen_oldmem_pfn_is_ram() documentation

The callback is only used for the vmcore nowadays. Reviewed-by: Boris Ostrovsky Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index 57409373750f..b242d1f4b4

[PATCH v2 2/9] x86/xen: simplify xen_oldmem_pfn_is_ram()

Let's simplify return handling. Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index b242d1f4b426..d1b38c77352b 100644 --- a/arch/x86/xen/mmu_hvm.c +++

[PATCH v2 3/9] x86/xen: print a warning when HVMOP_get_mem_type fails

HVMOP_get_mem_type is not expected to fail, "This call failing is indication of something going quite wrong and it would be good to know about this." [1] Let's add a pr_warn_once(). [1] https://lkml.kernel.org/r/3b935aa0-6d85-0bcd-100e-15098add3...@oracle.com Suggested-by: Boris Ostrovsky Signe

[PATCH v2 4/9] proc/vmcore: let pfn_is_ram() return a bool

The callback should deal with errors internally, it doesn't make sense to expose these via pfn_is_ram(). We'll rework the callbacks next. Right now we consider errors as if "it's RAM"; no functional change. Signed-off-by: David Hildenbrand --- fs/proc/vmcore.c | 8 1 file changed, 4 ins

[PATCH v2 5/9] proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks

Let's support multiple registered callbacks, making sure that registering vmcore callbacks cannot fail. Make the callback return a bool instead of an int, handling how to deal with errors internally. Drop unused HAVE_OLDMEM_PFN_IS_RAM. We soon want to make use of this infrastructure from other dri

[PATCH v2 6/9] virtio-mem: factor out hotplug specifics from virtio_mem_init() into virtio_mem_init_hotplug()

Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 81 - 1 file changed, 44 insertions(+), 37 deletions

[PATCH v2 7/9] virtio-mem: factor out hotplug specifics from virtio_mem_probe() into virtio_mem_init_hotplug()

Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 87 +++-- 1 file changed, 45 insertions(+), 42 deletions

[PATCH v2 8/9] virtio-mem: factor out hotplug specifics from virtio_mem_remove() into virtio_mem_deinit_hotplug()

Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers

[PATCH v2 9/9] virtio-mem: kdump mode to sanitize /proc/vmcore access

Although virtio-mem currently supports reading unplugged memory in the hypervisor, this will change in the future, indicated to the device via a new feature flag. We similarly sanitized /proc/kcore access recently. [1] Let's register a vmcore callback, to allow vmcore code to check if a PFN belong

Re: xen-balloon thread using 100% of CPU, regression in 5.4.150

On Tue, Oct 05, 2021 at 10:05:39AM +0200, Juergen Gross wrote: > On 04.10.21 11:14, Marek Marczykowski-Górecki wrote: > > On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote: > > > On 03.10.21 06:47, Marek Marczykowski-Górecki wrote: > > > > Hi, > > > > > > > > After updating a PVH domU

Re: xen-balloon thread using 100% of CPU, regression in 5.4.150

On Tue, Oct 5, 2021 at 4:05 AM Juergen Gross wrote: > > On 04.10.21 11:14, Marek Marczykowski-Górecki wrote: > > On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote: > >> On 03.10.21 06:47, Marek Marczykowski-Górecki wrote: > >>> Hi, > >>> > >>> After updating a PVH domU to 5.4.150, I se

[PATCH] xen/balloon: fix cancelled balloon action

In case a ballooning action is cancelled the new kernel thread handling the ballooning might end up in a busy loop. Fix that by handling the cancelled action gracefully. While at it introduce a short wait for the BP_WAIT case. Cc: sta...@vger.kernel.org Fixes: 8480ed9c2bbd56 ("xen/balloon: use a

[ovmf test] 165377: all pass - PUSHED

flight 165377 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/165377/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c49cb8f30e6223dc6b55903af178afa1dfde857f baseline version: ovmf 4cc1458dbe004b1d70534

[xen-unstable test] 165371: tolerable FAIL - PUSHED

flight 165371 xen-unstable real [real] flight 165381 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165371/ http://logs.test-lab.xenproject.org/osstest/logs/165381/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd6

Xen Security Advisory 386 v1 (CVE-2021-28702) - PCI devices with RMRRs not deassigned correctly

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28702 / XSA-386 PCI devices with RMRRs not deassigned correctly ISSUE DESCRIPTION = Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Res

Re: [PATCH v2 2/9] x86/xen: simplify xen_oldmem_pfn_is_ram()

On 10/5/21 8:14 AM, David Hildenbrand wrote: > Let's simplify return handling. > > Signed-off-by: David Hildenbrand Reviewed-by: Boris Ostrovsky

Re: [PATCH v2 3/9] x86/xen: print a warning when HVMOP_get_mem_type fails

On 10/5/21 8:14 AM, David Hildenbrand wrote: > HVMOP_get_mem_type is not expected to fail, "This call failing is > indication of something going quite wrong and it would be good to know > about this." [1] > > Let's add a pr_warn_once(). > > [1] https://lkml.kernel.org/r/3b935aa0-6d85-0bcd-100e-15

Re: [PATCH V4 3/3] libxl/arm: Add handling of extended regions for DomU

On 30.09.21 01:52, Oleksandr Tyshchenko wrote: Hi Stefano, Julien. From: Oleksandr Tyshchenko The extended region (safe range) is a region of guest physical address space which is unused and could be safely used to create grant/foreign mappings instead of wasting real RAM pages from the dom

Re: [PATCH V4 1/3] xen: Introduce "gpaddr_bits" field to XEN_SYSCTL_physinfo

On 05.10.21 00:11, Stefano Stabellini wrote: Hi Stefano On Sat, 2 Oct 2021, Oleksandr wrote: On 02.10.21 10:35, Julien Grall wrote: Thank you for your comments! Hi On Sat, 2 Oct 2021, 01:24 Stefano Stabellini, wrote: Bertrand, see comment on ID_AA64MMFR0_EL1 below,

Re: [adhoc test] 165359: tolerable truncated

On Mon, 4 Oct 2021, Stefano Stabellini wrote: > On Tue, 5 Oct 2021, Ian Jackson wrote: > > i...@xenbits.xen.org writes ("[adhoc test] 165359: tolerable truncated"): > > > [adhoc play] > > > harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin... > > > 165359: tolerable truncated

Re: [PATCH 1/2] mini-os: fix testbuilds regarding CONFIG_XC

Juergen Gross, le lun. 04 oct. 2021 16:19:23 +0200, a ecrit: > CONFIG_GC is requiring external support, so disable it in testbuilds. > > The only reason this is working right now is its usage being inside > a HAVE_LIBC section. > > Make that more obvious by making the default setting of CONFIG_XC

Re: [PATCH 2/2] mini-os: add config options for xen libraries

Juergen Gross, le lun. 04 oct. 2021 16:19:24 +0200, a ecrit: > Today close hooks into libxenctrl, libxenevtchn and libxengnttab are > under the CONFIG_XC umbrella. In order to support Mini-OS builds using > stable Xen libraries only, add CONFIG_LIBXENCTRL, CONFIG_LIBXENEVTCHN > and CONFIG_LIBXENGNT

Re: [PATCH v4 13/14] arm/libxl: Emulated PCI device tree node in libxl

On Tue, 5 Oct 2021, Rahul Singh wrote: > > On 5 Oct 2021, at 1:38 am, Stefano Stabellini > > wrote: > > > > On Mon, 4 Oct 2021, Rahul Singh wrote: > >> libxl will create an emulated PCI device tree node in the device tree to > >> enable the guest OS to discover the virtual PCI during guest boot.

[qemu-mainline test] 165374: regressions - FAIL

flight 165374 qemu-mainline real [real] flight 165389 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165374/ http://logs.test-lab.xenproject.org/osstest/logs/165389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH V4 3/3] libxl/arm: Add handling of extended regions for DomU

On Tue, 5 Oct 2021, Oleksandr wrote: > > From: Oleksandr Tyshchenko > > > > The extended region (safe range) is a region of guest physical > > address space which is unused and could be safely used to create > > grant/foreign mappings instead of wasting real RAM pages from > > the domain memory f

Re: [PATCH v4 10/11] xen/arm: Do not map PCI ECAM and MMIO space to Domain-0's p2m

On Tue, 5 Oct 2021, Oleksandr Andrushchenko wrote: > On 05.10.21 04:24, Stefano Stabellini wrote: > > On Mon, 4 Oct 2021, Oleksandr Andrushchenko wrote: > >> From: Oleksandr Andrushchenko > >> > >> PCI host bridges are special devices in terms of implementing PCI > >> passthrough. According to [1]

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

flight 165383 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/165383/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Patchew not working for xen-devel

Hi Fam, Patchew is not applying patches any longer from xen-devel. Would you be able to look into the issue? We are only 2 weeks away from the Xen 4.16 code freeze; it would be great to have Patchew working (the underlying gitlab-ci tests are known to work.) If you can't look into it at the moment

[linux-5.4 test] 165378: regressions - FAIL

flight 165378 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/165378/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 165206 Tests which are faili

Re: [PATCH] xen/balloon: fix cancelled balloon action

On 10/5/21 9:34 AM, Juergen Gross wrote: > In case a ballooning action is cancelled the new kernel thread handling > the ballooning might end up in a busy loop. > > Fix that by handling the cancelled action gracefully. > > While at it introduce a short wait for the BP_WAIT case. > > Cc: sta...@vg

[linux-linus test] 165379: regressions - FAIL

flight 165379 linux-linus real [real] flight 165393 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165379/ http://logs.test-lab.xenproject.org/osstest/logs/165393/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run

Re: [PATCH v4 10/11] xen/arm: Do not map PCI ECAM and MMIO space to Domain-0's p2m

On 06.10.21 00:43, Stefano Stabellini wrote: > On Tue, 5 Oct 2021, Oleksandr Andrushchenko wrote: >> On 05.10.21 04:24, Stefano Stabellini wrote: >>> On Mon, 4 Oct 2021, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko PCI host bridges are special devices in terms of i

[ovmf test] 165382: all pass - PUSHED

flight 165382 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/165382/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 942c9bd357d87cc6eed7c8250c213eff218d674e baseline version: ovmf c49cb8f30e6223dc6b559

[PATCH] x86/pvh: add prototype for xen_pvh_init()

xen_pvh_init() is lacking a prototype in a header, add it. Reported-by: kernel test robot Signed-off-by: Juergen Gross --- arch/x86/include/asm/xen/hypervisor.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h