Re: [PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology

Hi, Roger On 26.10.21 14:33, Roger Pau Monné wrote: > On Thu, Sep 30, 2021 at 10:52:22AM +0300, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Assign SBDF to the PCI devices being passed through with bus 0. >> The resulting topology is where PCIe devices reside on the bus 0

[qemu-mainline test] 166021: regressions - FAIL

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

Re: [PATCH] x86/smp: Factor out parts of native_smp_prepare_cpus()

On 03.11.21 00:36, Boris Ostrovsky wrote: Commit 66558b730f25 ("sched: Add cluster scheduler level for x86") introduced cpu_l2c_shared_map mask which is expected to be initialized by smp_op.smp_prepare_cpus(). That commit only updated native_smp_prepare_cpus() version but not xen_pv_smp_prepare_c

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

flight 166019 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/166019/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 165893 test-amd64-amd64-xl-qemuu-win7-amd64

[PATCH] x86/smp: Factor out parts of native_smp_prepare_cpus()

Commit 66558b730f25 ("sched: Add cluster scheduler level for x86") introduced cpu_l2c_shared_map mask which is expected to be initialized by smp_op.smp_prepare_cpus(). That commit only updated native_smp_prepare_cpus() version but not xen_pv_smp_prepare_cpus(). As result Xen PV guests crash in set_

Re: Arm EFI boot issue for Dom0 module listed inside subnode of chosen

On Tue, 2 Nov 2021, Luca Fancellu wrote: > Hi all, > > We recently discovered that there is a way to list Dom0 modules that is not > supported by the EFI boot, > It’s happened browsing some Wiki pages like this one: > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager >

Re: [PATCH] xen/efi: Fix Grub2 boot on arm64

On Tue, 2 Nov 2021, Luca Fancellu wrote: > + Ian Jackson for 4.16 release > > > On 2 Nov 2021, at 14:45, Jan Beulich wrote: > > > > On 02.11.2021 15:05, Luca Fancellu wrote: > >> The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882 > >> ("arm/efi: Use dom0less configuration whe

Re: [PATCH] xen/efi: Fix Grub2 boot on arm64

On Tue, 2 Nov 2021, Luca Fancellu wrote: > The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882 > ("arm/efi: Use dom0less configuration when using EFI boot") is > introducing a problem to boot Xen using Grub2 on ARM machine using EDK2. > > The problem comes from the function get_

Re: [PATCH-4.16 v2] xen/arm: fix SBDF calculation for vPCI MMIO handlers

On Tue, 2 Nov 2021, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > While in vPCI MMIO trap handlers for the guest PCI host bridge it is not > enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as > the base address may not be aligned in the way that the transl

[qemu-mainline test] 166017: regressions - FAIL

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

[linux-linus test] 165992: regressions - FAIL

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

Arm EFI boot issue for Dom0 module listed inside subnode of chosen

Hi all, We recently discovered that there is a way to list Dom0 modules that is not supported by the EFI boot, It’s happened browsing some Wiki pages like this one: https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager In that page the Dom0 modules are listed inside a sub

Re: [PATCH] xen/efi: Fix Grub2 boot on arm64

+ Ian Jackson for 4.16 release > On 2 Nov 2021, at 14:45, Jan Beulich wrote: > > On 02.11.2021 15:05, Luca Fancellu wrote: >> The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882 >> ("arm/efi: Use dom0less configuration when using EFI boot") is >> introducing a problem to boot

Re: [PATCH v2 1/1] xen: update system time immediately when VCPUOP_register_vcpu_info

Jan Beulich writes ("Re: [PATCH v2 1/1] xen: update system time immediately when VCPUOP_register_vcpu_info"): > I don't see any noteworthy risks - a call to a function gets added > in a 2nd place; the function itself has been working fine for years, > and it is fine to be used in this new context.

Re: [PATCH v2 1/1] xen: update system time immediately when VCPUOP_register_vcpu_info

On 02.11.2021 17:00, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH v2 1/1] xen: update system time immediately > when VCPUOP_register_vcpu_info"): >> On 25.10.2021 19:35, Dongli Zhang wrote: >>> The guest may access the pv vcpu_time_info immediately after >>> VCPUOP_register_vcpu_info. This

Bug Bounty program

Recently we (the Xen security team) have been invited by HackerOne to join the Internet Bug Bounty https://hackerone.com/ibb (citing the original mail): > The Internet Bug Bounty was created with > the goal of helping to secure critical open source infrastructure. > Af

Re: [PATCH v2 1/1] xen: update system time immediately when VCPUOP_register_vcpu_info

Jan Beulich writes ("Re: [PATCH v2 1/1] xen: update system time immediately when VCPUOP_register_vcpu_info"): > On 25.10.2021 19:35, Dongli Zhang wrote: > > The guest may access the pv vcpu_time_info immediately after > > VCPUOP_register_vcpu_info. This is to borrow the idea of > > VCPUOP_register

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers [and 2 more messages]

Stefano Stabellini writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers [and 2 more messages]"): > This patch [1] is a straightforward 2 lines fix for vpci on ARM. There > is no risk for the release as the source file affected only builds when > CONFIG_HAS_VPCI is enabled, an

Re: [PATCH for-4.16 v4] gnttab: allow setting max version per-domain

On 02/11/2021 15:00, Julien Grall wrote: > Hi Andree, > > On 02/11/2021 14:34, Andrew Cooper wrote: >> Same too for >> evtchn, but we've already taken a patch to knobble fifo support. > > I know that Amazon submitted a patch to allow disabling FIFO [1]. But > AFAIK, this is not yet merged because o

Re: [PATCH] x86/kexec: Fix crash on transition to a 32bit kernel on AMD hardware

Andrew Cooper writes ("Re: [PATCH] x86/kexec: Fix crash on transition to a 32bit kernel on AMD hardware"): > On 01/11/2021 12:13, Ian Jackson wrote: > > Andrew Cooper writes ("Re: [PATCH] x86/kexec: Fix crash on transition to a > > 32bit kernel on AMD hardware"): > >> This path is only taken for

Re: [PATCH for-4.16] x86/shstk: Fix use of shadow stacks with XPTI active

Jan Beulich writes ("Re: [PATCH for-4.16] x86/shstk: Fix use of shadow stacks with XPTI active"): > On 02.11.2021 15:39, Andrew Cooper wrote: > > The call to setup_cpu_root_pgt(0) in smp_prepare_cpus() is too early. It > > clones the BSP's stack while the .data mapping is still in use, causing al

Re: [PULL 00/20] Migration 20211031 patches

On 11/1/21 6:08 PM, Juan Quintela wrote: The following changes since commit af531756d25541a1b3b3d9a14e72e7fedd941a2e: Merge remote-tracking branch 'remotes/philmd/tags/renesas-20211030' into staging (2021-10-30 11:31:41 -0700) are available in the Git repository at: https://github.com/j

Re: [PATCH for-4.16 v4] gnttab: allow setting max version per-domain

On Tue, Nov 02, 2021 at 02:34:03PM +, Andrew Cooper wrote: > On 30/10/2021 08:53, Roger Pau Monné wrote: > > On Fri, Oct 29, 2021 at 05:39:52PM +0100, Andrew Cooper wrote: > >> On 29/10/2021 08:59, Roger Pau Monne wrote: > >>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c > >

Re: [PATCH v2 6/7] xen: Switch to byteswap.h

On 22.10.2021 12:47, Lin Liu wrote: > @@ -28,7 +28,7 @@ static inline void put_unaligned_le32(u32 val, void *p) > > #endif > > -#define get_le32(p) le32_to_cpup((const uint32_t *)(p)) > +#define get_le32(p) le32_to_cpu(*(const uint32_t *)(p)) While here the adjustment may be okay as there is

Re: [PATCH v2 5/7] xen/xsm: Switch to byteswap.h

On 22.10.2021 17:46, Daniel P. Smith wrote: > On 10/22/21 6:47 AM, Lin Liu wrote: >> Update to use byteswap.h to swap bytes >> >> No functional change >> >> Signed-off-by: Lin Liu > > Reviewed by: Daniel P. Smith Acked-by: Jan Beulich

Re: [PATCH for-4.16] x86/shstk: Fix use of shadow stacks with XPTI active

On 02.11.2021 15:39, Andrew Cooper wrote: > The call to setup_cpu_root_pgt(0) in smp_prepare_cpus() is too early. It > clones the BSP's stack while the .data mapping is still in use, causing all > mappings to be fully read read/write (and with no guard pages either). This > ultimately causes #DF

Re: [PATCH v2 2/7] crypto/vmac: Simplify code with byteswap.h

On 22.10.2021 12:47, Lin Liu wrote: > This file has its own implementation of swap bytes. Clean up > the code with xen/byteswap.h. > > No functional change. > > Signed-off-by: Lin Liu Acked-by: Jan Beulich

Re: [PATCH for-4.16 v4] gnttab: allow setting max version per-domain

Hi Andree, On 02/11/2021 14:34, Andrew Cooper wrote: Same too for evtchn, but we've already taken a patch to knobble fifo support. I know that Amazon submitted a patch to allow disabling FIFO [1]. But AFAIK, this is not yet merged because of disagrement (?) on the approach. Cheers, [1] htt

Re: [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap

On Tue, Nov 02, 2021 at 03:00:24PM +0100, Jan Beulich wrote: > On 02.11.2021 12:03, Roger Pau Monné wrote: > > On Tue, Nov 02, 2021 at 11:13:08AM +0100, Jan Beulich wrote: > >> On 25.10.2021 12:28, Roger Pau Monné wrote: > >>> On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote: > The

Re: [PATCH] xen/efi: Fix Grub2 boot on arm64

On 02.11.2021 15:05, Luca Fancellu wrote: > The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882 > ("arm/efi: Use dom0less configuration when using EFI boot") is > introducing a problem to boot Xen using Grub2 on ARM machine using EDK2. > > The problem comes from the function get

[PATCH for-4.16] x86/shstk: Fix use of shadow stacks with XPTI active

The call to setup_cpu_root_pgt(0) in smp_prepare_cpus() is too early. It clones the BSP's stack while the .data mapping is still in use, causing all mappings to be fully read read/write (and with no guard pages either). This ultimately causes #DF when trying to enter the dom0 kernel for the first

Re: [PATCH for-4.16 v4] gnttab: allow setting max version per-domain

On 30/10/2021 08:53, Roger Pau Monné wrote: > On Fri, Oct 29, 2021 at 05:39:52PM +0100, Andrew Cooper wrote: >> On 29/10/2021 08:59, Roger Pau Monne wrote: >>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c >>> index e510395d08..f94f0f272c 100644 >>> --- a/xen/common/grant_table.c

Re: [PATCH V4 04/50] x86/xen: Add xenpv_restore_regs_and_return_to_usermode()

On Tue, Nov 02, 2021 at 12:22:50PM +0100, H. Peter Anvin wrote: > It would be interesting to have an "override function with jmp" > alternatives macro. It doesn't require any changes to the alternatives > mechanism proper (but possibly to objtool): it would just insert an > alternatives entry witho

Re: [PATCH v2 1/7] xen: implement byteswap.h

On 22.10.2021 12:47, Lin Liu wrote: > --- /dev/null > +++ b/xen/include/xen/byteswap.h > @@ -0,0 +1,93 @@ > +#ifndef _BYTESWAP_H > +#define _BYTESWAP_H > + > +#include > + > +#if !__has_builtin(__builtin_bswap16) > +static always_inline uint16_t __builtin_bswap16(uint16_t val) > +{ > +return (

Re: [PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

Hi Roger, On 02/11/2021 11:50, Roger Pau Monné wrote: On Tue, Nov 02, 2021 at 12:19:13PM +0100, Jan Beulich wrote: On 26.10.2021 12:52, Roger Pau Monné wrote: On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote: --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header

Re: [PATCH for-4.16 2/2] xen: Report grant table v1/v2 capabilities to the toolstack

On 30/10/2021 12:20, Roger Pau Monné wrote: > On Fri, Oct 29, 2021 at 06:38:13PM +0100, Andrew Cooper wrote: >> In order to let the toolstack be able to set the gnttab version on a >> per-domain basis, it needs to know which ABIs Xen supports. Introduce >> XEN_SYSCTL_PHYSCAP_gnttab_v{1,2} for the

Re: [PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

On 02.11.21 15:54, Jan Beulich wrote: > On 02.11.2021 12:50, Roger Pau Monné wrote: >> On Tue, Nov 02, 2021 at 12:19:13PM +0100, Jan Beulich wrote: >>> On 26.10.2021 12:52, Roger Pau Monné wrote: On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote: > --- a/xen/drivers

[PATCH] xen/efi: Fix Grub2 boot on arm64

The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882 ("arm/efi: Use dom0less configuration when using EFI boot") is introducing a problem to boot Xen using Grub2 on ARM machine using EDK2. The problem comes from the function get_parent_handle(...) that inside uses the HandleProto

Re: [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap

On 02.11.2021 12:03, Roger Pau Monné wrote: > On Tue, Nov 02, 2021 at 11:13:08AM +0100, Jan Beulich wrote: >> On 25.10.2021 12:28, Roger Pau Monné wrote: >>> On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote: The two are really meant to be independent settings; iov_supports_xt()

Re: [PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

On 02.11.2021 12:50, Roger Pau Monné wrote: > On Tue, Nov 02, 2021 at 12:19:13PM +0100, Jan Beulich wrote: >> On 26.10.2021 12:52, Roger Pau Monné wrote: >>> On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote: --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/hea

Re: [PULL 8/9] pci: Export pci_for_each_device_under_bus*()

On 11/1/21 7:44 PM, Michael S. Tsirkin wrote: From: Peter Xu They're actually more commonly used than the helper without _under_bus, because most callers do have the pci bus on hand. After exporting we can switch a lot of the call sites to use these two helpers. Reviewed-by: David Hildenbrand

Re: [qemu-mainline test] 165982: regressions - FAIL

On Tue, Nov 2, 2021 at 7:20 AM osstest service owner wrote: > > flight 165982 qemu-mainline real [real] > http://logs.test-lab.xenproject.org/osstest/logs/165982/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-i386

Re: Arch-neutral name for hardware interrupt support

On 01.11.2021 11:47, Andrew Cooper wrote: > Hello, > > On ARM, the GIC is a hard prerequisite for VMs. > > I can't remember what the state of RISCV is, but IIRC there is still > some debate over how interrupts are expected to work under virt. > > On x86, the story is very different.  PV have no

Re: [PATCH] x86/kexec: Fix crash on transition to a 32bit kernel on AMD hardware

On 29.10.2021 01:26, Andrew Cooper wrote: > The `ljmp *mem` instruction is (famously?) not binary compatible between Intel > and AMD CPUS. The AMD-compatible version would require .long to be .quad in > the second hunk. >From all sources I have the incompatibility is only with REX.W: Intel honors

Re: [PATCH] x86/passthrough: Fix hvm_gsi_eoi() build with GCC 12

On 27.10.2021 22:07, Andrew Cooper wrote: > GCC master (nearly version 12) complains: > > hvm.c: In function 'hvm_gsi_eoi': > hvm.c:905:10: error: the comparison will always evaluate as 'true' for the > address of 'dpci' will never be NULL [-Werror=address] > 905 | if ( !pirq_dpci(pi

Re: [PATCH] x86/cpuid: prevent decreasing of hypervisor max leaf on migration

On Tue, Nov 02, 2021 at 01:00:07PM +0100, Jan Beulich wrote: > On 27.10.2021 16:00, Roger Pau Monne wrote: > > In order to be compatible with previous Xen versions, and not change > > max hypervisor leaf as a result of a migration, keep the clamping of > > the maximum leaf value provided to XEN_CPU

Re: [PATCH] x86/hpet: setup HPET even when disabled due to stopping in deep C states

On 26.10.2021 17:12, Roger Pau Monne wrote: > Always allow the HPET to be setup, but don't report a frequency back > to the platform time source probe in order to avoid it from being > selected as a valid timer if it's not usable. > > Doing the setup even when not intended to be used as a platform

Re: [PATCH v2 1/1] xen: update system time immediately when VCPUOP_register_vcpu_info

On 25.10.2021 19:35, Dongli Zhang wrote: > The guest may access the pv vcpu_time_info immediately after > VCPUOP_register_vcpu_info. This is to borrow the idea of > VCPUOP_register_vcpu_time_memory_area, where the > force_update_vcpu_system_time() is called immediately when the new memory > area is

Re: [PATCH for-4.16 v4] gnttab: allow setting max version per-domain

On 29.10.2021 09:59, Roger Pau Monne wrote: > @@ -1917,11 +1918,33 @@ active_alloc_failed: > } > > int grant_table_init(struct domain *d, int max_grant_frames, > - int max_maptrack_frames) > + int max_maptrack_frames, unsigned int options) > { > str

Re: [PATCH for-4.16 2/2] xen: Report grant table v1/v2 capabilities to the toolstack

On 30.10.2021 13:20, Roger Pau Monné wrote: > On Fri, Oct 29, 2021 at 06:38:13PM +0100, Andrew Cooper wrote: >> In order to let the toolstack be able to set the gnttab version on a >> per-domain basis, it needs to know which ABIs Xen supports. Introduce >> XEN_SYSCTL_PHYSCAP_gnttab_v{1,2} for the

Re: [PATCH] x86/cpuid: prevent decreasing of hypervisor max leaf on migration

On 27.10.2021 16:00, Roger Pau Monne wrote: > In order to be compatible with previous Xen versions, and not change > max hypervisor leaf as a result of a migration, keep the clamping of > the maximum leaf value provided to XEN_CPUID_MAX_NUM_LEAVES, instead > of doing it based on the domain type. Al

Re: [PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

On Tue, Nov 02, 2021 at 12:19:13PM +0100, Jan Beulich wrote: > On 26.10.2021 12:52, Roger Pau Monné wrote: > > On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote: > >> --- a/xen/drivers/vpci/header.c > >> +++ b/xen/drivers/vpci/header.c > >> @@ -451,6 +451,32 @@ static void cmd

Re: [PATCH V4 04/50] x86/xen: Add xenpv_restore_regs_and_return_to_usermode()

On November 2, 2021 10:49:44 AM GMT+01:00, Borislav Petkov wrote: >On Tue, Nov 02, 2021 at 05:19:46PM +0800, Lai Jiangshan wrote: >> It will add a 5-byte NOP at the beginning of the native >> swapgs_restore_regs_and_return_to_usermode. > >So? > It would be interesting to have an "override fun

Re: [PATCH v5 07/10] libxl: Only map legacy PCI IRQs if they are supported

On 02.11.21 13:32, Jan Beulich wrote: > On 25.10.2021 15:38, Oleksandr Andrushchenko wrote: >> On 25.10.21 16:22, Roger Pau Monné wrote: >>> On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote: --- a/tools/libs/light/libxl_pci.c +++ b/tools/libs/light/libxl_pci.c >>>

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

flight 165979 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/165979/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165966 test-armhf-armhf-libvirt 16 save

Re: [PATCH v5 07/10] libxl: Only map legacy PCI IRQs if they are supported

On 25.10.2021 15:38, Oleksandr Andrushchenko wrote: > On 25.10.21 16:22, Roger Pau Monné wrote: >> On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote: >>> --- a/tools/libs/light/libxl_pci.c >>> +++ b/tools/libs/light/libxl_pci.c >>> @@ -1364,6 +1364,15 @@ static void pci_add_ti

Re: [PATCH v2 07/15] xen: generate hypercall interface related code

On 02.11.21 11:43, Michal Orzel wrote: Hi Juergen, On 01.11.2021 16:20, Juergen Gross wrote: Instead of repeating similar data multiple times use a single source file and a generator script for producing prototypes and call sequences of the hypercalls. As the script already knows the number of

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers [and 2 more messages]

On 02.11.21 11:32, Julien Grall wrote: > Hi Oleksandr, > > On 02/11/2021 07:16, Oleksandr Andrushchenko wrote: >> >> >> On 01.11.21 23:06, Stefano Stabellini wrote: >>> On Mon, 1 Nov 2021, Ian Jackson wrote: Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO

[PATCH-4.16 v2] xen/arm: fix SBDF calculation for vPCI MMIO handlers

From: Oleksandr Andrushchenko While in vPCI MMIO trap handlers for the guest PCI host bridge it is not enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as the base address may not be aligned in the way that the translation always work. If not adjusted with respect to the base a

[qemu-mainline test] 165982: regressions - FAIL

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

Re: [PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

On 26.10.2021 12:52, Roger Pau Monné wrote: > On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote: >> --- a/xen/drivers/vpci/header.c >> +++ b/xen/drivers/vpci/header.c >> @@ -451,6 +451,32 @@ static void cmd_write(const struct pci_dev *pdev, >> unsigned int reg, >> pc

Re: [PATCH v3 06/11] vpci/header: Handle p2m range sets per BAR

On 26.10.2021 11:40, Roger Pau Monné wrote: > On Mon, Oct 25, 2021 at 11:51:57AM +, Oleksandr Andrushchenko wrote: >> Hi, Roger! >> Could you please take a look at the below? >> Jan was questioning the per BAR range set approach, so it >> is crucial for the maintainer (you) to answer here. > >

Re: [PATCH v3 09/11] vpci/header: Reset the command register when adding devices

Hi, Roger! On 26.10.21 14:00, Roger Pau Monné wrote: > On Thu, Sep 30, 2021 at 10:52:21AM +0300, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Reset the command register when passing through a PCI device: >> it is possible that when passing through a PCI device its memory

Re: [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap

On Tue, Nov 02, 2021 at 11:13:08AM +0100, Jan Beulich wrote: > On 25.10.2021 12:28, Roger Pau Monné wrote: > > On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote: > >> The two are really meant to be independent settings; iov_supports_xt() > >> using || instead of && was simply wrong. The c

Re: [PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

Hi, Roger! On 26.10.21 13:52, Roger Pau Monné wrote: > On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Add basic emulation support for guests. At the moment only emulate >> PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet a

Re: [PATCH v2 07/15] xen: generate hypercall interface related code

Hi Juergen, On 01.11.2021 16:20, Juergen Gross wrote: > Instead of repeating similar data multiple times use a single source > file and a generator script for producing prototypes and call sequences > of the hypercalls. > > As the script already knows the number of parameters used add generating

Re: [PATCH v3 07/11] vpci/header: program p2m with guest BAR view

Hi, Roger! On 26.10.21 13:35, Roger Pau Monné wrote: > On Thu, Sep 30, 2021 at 10:52:19AM +0300, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Take into account guest's BAR view and program its p2m accordingly: >> gfn is guest's view of the BAR and mfn is the physical BAR

Re: [PATCH v3 06/11] vpci/header: Handle p2m range sets per BAR

Hi, Roger! On 26.10.21 12:08, Roger Pau Monné wrote: > On Thu, Sep 30, 2021 at 10:52:18AM +0300, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Instead of handling a single range set, that contains all the memory >> regions of all the BARs and ROM, have them per BAR. >> >>

Re: [xen-unstable test] 165973: regressions - FAIL

On 02.11.2021 04:07, osstest service owner wrote: > flight 165973 xen-unstable real [real] > flight 165977 xen-unstable real-retest [real] > http://logs.test-lab.xenproject.org/osstest/logs/165973/ > http://logs.test-lab.xenproject.org/osstest/logs/165977/ > > Regressions :-( > > Tests which did

Re: [PATCH v3 04/11] vpci/header: Add and remove register handlers dynamically

On 02.11.21 12:03, Roger Pau Monné wrote: > On Mon, Nov 01, 2021 at 09:18:17AM +, Oleksandr Andrushchenko wrote: +if ( rc ) +gdprintk(XENLOG_ERR, + "%pp: failed to add BAR handlers for dom%pd: %d\n", + &pdev->sbdf, d, rc); +

Re: [PATCH v2 1/3] x86/IOMMU: mark IOMMU / intremap not in use when ACPI tables are missing

On Tue, Nov 02, 2021 at 11:07:25AM +0100, Jan Beulich wrote: > On 22.10.2021 17:52, Roger Pau Monné wrote: > > On Thu, Oct 21, 2021 at 11:58:18AM +0200, Jan Beulich wrote: > >> x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC > >> mode (physical vs clustered) depends on iommu

[libvirt test] 165985: regressions - FAIL

flight 165985 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/165985/ 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

Re: [PATCH v2 0/3] x86/IOMMU: enabled / intremap handling

On 21.10.2021 11:57, Jan Beulich wrote: > In the course of reading the response to v1 (patch 1 only) I realized > that not only that patch needs further adjustment, but that also > further changes are needed (and there's likely yet more amiss). > > 1: x86/IOMMU: mark IOMMU / intremap not in use wh

Re: [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap

On 25.10.2021 12:28, Roger Pau Monné wrote: > On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote: >> The two are really meant to be independent settings; iov_supports_xt() >> using || instead of && was simply wrong. The corrected check is, >> however, redundant, just like the (correct) one

Re: [PATCH v2 1/3] x86/IOMMU: mark IOMMU / intremap not in use when ACPI tables are missing

On 22.10.2021 17:52, Roger Pau Monné wrote: > On Thu, Oct 21, 2021 at 11:58:18AM +0200, Jan Beulich wrote: >> x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC >> mode (physical vs clustered) depends on iommu_intremap, that variable >> needs to be set to off as soon as we know

Re: [PATCH 10/12] xen/x86: call hypercall handlers via switch statement

On 02.11.21 10:54, Jan Beulich wrote: On 28.10.2021 16:32, Juergen Gross wrote: On 21.10.21 16:41, Jan Beulich wrote: On 15.10.2021 14:51, Juergen Gross wrote: Instead of using a function table use the generated switch statement macros for calling the appropriate hypercall handlers. This is b

Re: [PATCH v3 04/11] vpci/header: Add and remove register handlers dynamically

On Mon, Nov 01, 2021 at 09:18:17AM +, Oleksandr Andrushchenko wrote: > > >> +if ( rc ) > >> +gdprintk(XENLOG_ERR, > >> + "%pp: failed to add BAR handlers for dom%pd: %d\n", > >> + &pdev->sbdf, d, rc); > >> +return rc; > >> +} > >> + > >> +int vpc

Re: [PATCH 10/12] xen/x86: call hypercall handlers via switch statement

On 28.10.2021 16:32, Juergen Gross wrote: > On 21.10.21 16:41, Jan Beulich wrote: >> On 15.10.2021 14:51, Juergen Gross wrote: >>> Instead of using a function table use the generated switch statement >>> macros for calling the appropriate hypercall handlers. >>> >>> This is beneficial to performanc

Re: [PATCH V4 04/50] x86/xen: Add xenpv_restore_regs_and_return_to_usermode()

On Tue, Nov 02, 2021 at 05:19:46PM +0800, Lai Jiangshan wrote: > It will add a 5-byte NOP at the beginning of the native > swapgs_restore_regs_and_return_to_usermode. So? > I avoided adding unneeded code in the native code even if it is NOPs > and avoided melting xenpv-one into the native one whi

Re: [PATCH v4 6/6] x86/P2M: relax permissions of PVH Dom0's MMIO entries

On 22.10.2021 15:25, Roger Pau Monné wrote: > On Wed, Sep 29, 2021 at 03:15:48PM +0200, Jan Beulich wrote: >> To become independent of the sequence of mapping operations, permit >> "access" to accumulate for Dom0, noting that there's not going to be an >> introspection agent for it which this might

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers [and 2 more messages]

Hi Oleksandr, On 02/11/2021 07:16, Oleksandr Andrushchenko wrote: On 01.11.21 23:06, Stefano Stabellini wrote: On Mon, 1 Nov 2021, Ian Jackson wrote: Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers"): On 28/10/2021 16:54, Ian Jackson wrote: There are

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

On Tue, Nov 02, 2021 at 09:07:56AM +, Oleksandr Andrushchenko wrote: > > > On 02.11.21 10:48, Roger Pau Monné wrote: > > On Mon, Nov 01, 2021 at 06:14:40AM +, Oleksandr Andrushchenko wrote: > >> > >> On 29.10.21 10:33, Roger Pau Monné wrote: > >>> On Thu, Oct 28, 2021 at 05:55:25PM +,

Re: [PATCH V4 04/50] x86/xen: Add xenpv_restore_regs_and_return_to_usermode()

On 2021/11/2 16:58, Borislav Petkov wrote: */ - ALTERNATIVE "", "jmp swapgs_restore_regs_and_return_to_usermode", \ + ALTERNATIVE "", "jmp xenpv_restore_regs_and_return_to_usermode", \ Instead of sprinkling all those ALTERNATIVE calls everywhere, why don't you simply jump

[PATCH v2] xen/balloon: rename alloc/free_xenballooned_pages

alloc_xenballooned_pages() and free_xenballooned_pages() are used as direct replacements of xen_alloc_unpopulated_pages() and xen_free_unpopulated_pages() in case CONFIG_XEN_UNPOPULATED_ALLOC isn't defined. Guard both functions with !CONFIG_XEN_UNPOPULATED_ALLOC and rename them to the xen_*() vari

[PATCH v4] xen/balloon: add late_initcall_sync() for initial ballooning done

When running as PVH or HVM guest with actual memory < max memory the hypervisor is using "populate on demand" in order to allow the guest to balloon down from its maximum memory size. For this to work correctly the guest must not touch more memory pages than its target memory size as otherwise the

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

On 02.11.21 10:48, Roger Pau Monné wrote: > On Mon, Nov 01, 2021 at 06:14:40AM +, Oleksandr Andrushchenko wrote: >> >> On 29.10.21 10:33, Roger Pau Monné wrote: >>> On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote: On 28.10.21 19:03, Roger Pau Monné wrote: > On

Re: [PATCH V4 04/50] x86/xen: Add xenpv_restore_regs_and_return_to_usermode()

On Tue, Oct 26, 2021 at 10:13:34PM +0800, Lai Jiangshan wrote: > From: Lai Jiangshan > > While in the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the > trampoline stack. But XEN pv doesn't use trampoline stack, so > PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack. Hence source

Re: Arch-neutral name for hardware interrupt support

On Mon, Nov 01, 2021 at 10:47:26AM +, Andrew Cooper wrote: > Hello, > > On ARM, the GIC is a hard prerequisite for VMs. > > I can't remember what the state of RISCV is, but IIRC there is still > some debate over how interrupts are expected to work under virt. > > On x86, the story is very di

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

On Mon, Nov 01, 2021 at 06:14:40AM +, Oleksandr Andrushchenko wrote: > > > On 29.10.21 10:33, Roger Pau Monné wrote: > > On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote: > >> > >> On 28.10.21 19:03, Roger Pau Monné wrote: > >>> On Thu, Oct 28, 2021 at 02:23:34PM +,

Re: Arch-neutral name for hardware interrupt support

Hi, > On 2 Nov 2021, at 07:16, Alistair Francis wrote: > > On Tue, Nov 2, 2021 at 6:33 AM Stefano Stabellini > wrote: >> >> +Bertrand >> >> On Mon, 1 Nov 2021, Andrew Cooper wrote: >>> Hello, >>> >>> On ARM, the GIC is a hard prerequisite for VMs. >>> >>> I can't remember what the state of

RE: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

Hi Oleksandr, > -Original Message- > From: Oleksandr Andrushchenko > Sent: 2021年11月2日 15:47 > To: Wei Chen ; Roger Pau Monné > Cc: Julien Grall ; Bertrand Marquis > ; sstabell...@kernel.org; Rahul Singh > ; xen-devel@lists.xenproject.org > Subject: Re: [PATCH] xen/arm: fix SBDF calculati

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

Hi, On 02.11.21 09:37, Wei Chen wrote: > Hi Oleksandr, > > On 2021/11/1 14:14, Oleksandr Andrushchenko wrote: >> >> >> On 29.10.21 10:33, Roger Pau Monné wrote: >>> On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote: On 28.10.21 19:03, Roger Pau Monné wrote: > On

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers

Hi Oleksandr, On 2021/11/1 14:14, Oleksandr Andrushchenko wrote: On 29.10.21 10:33, Roger Pau Monné wrote: On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote: On 28.10.21 19:03, Roger Pau Monné wrote: On Thu, Oct 28, 2021 at 02:23:34PM +, Oleksandr Andrushchenko wr

[[PATCH v2.1 07/15] xen: generate hypercall interface related code

Instead of repeating similar data multiple times use a single source file and a generator script for producing prototypes and call sequences of the hypercalls. As the script already knows the number of parameters used add generating a macro for populating an array with the number of parameters per

Re: [PATCH v2 07/15] xen: generate hypercall interface related code

On 01.11.21 16:20, Juergen Gross wrote: Instead of repeating similar data multiple times use a single source file and a generator script for producing prototypes and call sequences of the hypercalls. As the script already knows the number of parameters used add generating a macro for populating

Re: Arch-neutral name for hardware interrupt support

On Tue, Nov 2, 2021 at 6:33 AM Stefano Stabellini wrote: > > +Bertrand > > On Mon, 1 Nov 2021, Andrew Cooper wrote: > > Hello, > > > > On ARM, the GIC is a hard prerequisite for VMs. > > > > I can't remember what the state of RISCV is, but IIRC there is still > > some debate over how interrupts ar

Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO handlers [and 2 more messages]

On 01.11.21 23:06, Stefano Stabellini wrote: > On Mon, 1 Nov 2021, Ian Jackson wrote: >> Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI >> MMIO handlers"): >>> On 28/10/2021 16:54, Ian Jackson wrote: There are a number of patches that I'm getting CC'd on related to