Re: [PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations

2021-09-06 Thread Oleksandr Andrushchenko
On 06.09.21 11:48, Julien Grall wrote: > On 06/09/2021 08:02, Oleksandr Andrushchenko wrote: >> Hi, Julien! > > Hi Oleksandr, > >> On 03.09.21 12:04, Julien Grall wrote: >>> Hi Oleksandr, >>> >>> On 03/09/2021 09:33, Oleksandr Andr

Re: [PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations

2021-09-06 Thread Oleksandr Andrushchenko
Hi, Julien! On 03.09.21 12:04, Julien Grall wrote: > Hi Oleksandr, > > On 03/09/2021 09:33, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> vPCI may map and unmap PCI device memory (BARs) being passed through which >> may take a lot of time.

Re: [PATCH 05/11] xen/arm: Mark device as PCI while creating one

2021-09-03 Thread Oleksandr Andrushchenko
On 03.09.21 15:41, Jan Beulich wrote: > On 03.09.2021 10:33, Oleksandr Andrushchenko wrote: >> --- a/xen/drivers/passthrough/pci.c >> +++ b/xen/drivers/passthrough/pci.c >> @@ -1301,6 +1301,9 @@ static int iommu_add_device(struct pci_dev *pdev) >> if ( !is

Re: [PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported

2021-09-03 Thread Oleksandr Andrushchenko
Hello, Juergen! On 03.09.21 13:26, Juergen Gross wrote: > On 03.09.21 10:33, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Arm's PCI passthrough implementation doesn't support legacy interrupts, >> but MSI/MSI-X. This can be the case

[PATCH 9/9] vpci/header: Use pdev's domain instead of vCPU

2021-09-03 Thread Oleksandr Andrushchenko
From: Rahul Singh Fixes: 9c244fdef7e7 ("vpci: add header handlers") Signed-off-by: Rahul Singh Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/header.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/head

[PATCH 8/9] vpci/header: Reset the command register when adding devices

2021-09-03 Thread Oleksandr Andrushchenko
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 decoding bits in the command register are already set. Thus, a guest OS may not write to the command register to update memory decoding, so

[PATCH 7/9] vpci/header: program p2m with guest BAR view

2021-09-03 Thread Oleksandr Andrushchenko
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 value as set up by the host bridge in the hardware domain. This way hardware doamin sees physical BAR values and guest sees emu

[PATCH 6/9] vpci/header: Handle p2m range sets per BAR

2021-09-03 Thread Oleksandr Andrushchenko
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. This is in preparation of making non-identity mappings in p2m for the MMIOs/ROM. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci

[PATCH 5/9] vpci/header: Implement guest BAR register handlers

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Emulate guest BAR register values: this allows creating a guest view of the registers and emulates size and properties probe as it is done during PCI device enumeration by the guest. ROM BAR is only handled for the hardware domain and for guest domains there is a

[PATCH 4/9] vpci/header: Add and remove register handlers dynamically

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Add relevant vpci register handlers when assigning PCI device to a domain and remove those when de-assigning. This allows having different handlers for different domains, e.g. hwdom and other guests. Use stubs for guest domains for now. Signed-off-by: Oleksandr

[PATCH 3/9] vpci/header: Move register assignments from init_bars

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko This is in preparation for dynamic assignment of the vpci register handlers depending on the domain: hwdom or guest. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/header.c | 83 ++- 1 file changed, 56 insertions

[PATCH 2/9] vpci: Add hooks for PCI device assign/de-assign

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko When a PCI device gets assigned/de-assigned some work on vPCI side needs to be done for that device. Introduce a pair of hooks so vPCI can handle that. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/passthrough/pci.c | 9 + xen/drivers/vpci

[PATCH 0/9] PCI devices passthrough on Arm, part 3

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Hi, all! This patch series is focusing on vPCI and adds support for non-identity PCI BAR mappings which is required while passing through a PCI device to a guest. The highlights are: - Add relevant vpci register handlers when assigning PCI device to a domain and

[PATCH 1/9] vpci: Make vpci registers removal a dedicated function

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko This is in preparation for dynamic assignment of the vpci register handlers depending on the domain: hwdom or guest. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/vpci.c | 7 ++- xen/include/xen/vpci.h | 2 ++ 2 files changed, 8 insertions

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

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Host bridge controller's ECAM space is mapped into Domain-0's p2m, thus it is not possible to trap the same for vPCI via MMIO handlers. For this to work we need to not map those while constructing the domain. Note, that during Domain-0 creation there is

[PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko vPCI may map and unmap PCI device memory (BARs) being passed through which may take a lot of time. For this those operations may be deferred to be performed later, so that they can be safely preempted. Run the corresponding vPCI code while switching a vCPU. Signed

[PATCH 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko In order vPCI to work it needs all access to PCI configuration space (ECAM) to be synchronized among all entities, e.g. hardware domain and guests. For that implement PCI host bridge specific callbacks to properly setup those ranges depending on particular host

[PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Arm's PCI passthrough implementation doesn't support legacy interrupts, but MSI/MSI-X. This can be the case for other platforms too. For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add it to the CFLAGS and compile the relevant code in the

[PATCH 07/11] libxl: Allow removing PCI devices for all types of domains

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko The PCI device remove path may now be used by PVH on ARM, so the assert is no longer valid. Signed-off-by: Oleksandr Andrushchenko Cc: Ian Jackson Cc: Juergen Gross --- tools/libs/light/libxl_pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/libs

[PATCH 06/11] xen/domain: Call pci_release_devices() when releasing domain resources

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Tyshchenko This is the very same what we do for DT devices. What is more that x86 already calls pci_release_devices(). Signed-off-by: Oleksandr Tyshchenko --- xen/arch/arm/domain.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/domain.c

[PATCH 05/11] xen/arm: Mark device as PCI while creating one

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko While adding a PCI device mark it as such, so other frameworks can distinguish it form DT devices. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/passthrough/pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/drivers/passthrough/pci.c b/xen

[PATCH 04/11] xen/device-tree: Make dt_find_node_by_phandle global

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Make dt_find_node_by_phandle globally visible, so it can be re-used by other frameworks. Signed-off-by: Oleksandr Andrushchenko --- xen/common/device_tree.c | 2 +- xen/include/xen/device_tree.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff

[PATCH 03/11] xen/arm: Introduce pci_find_host_bridge_node helper

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Get host bridge node given a PCI device attached to it. This helper will be re-used for adding PCI devices by the subsequent patches. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Tyshchenko --- xen/arch/arm/pci/pci-host-common.c | 17

[PATCH 02/11] xen/arm: Add dev_to_pci helper

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Add a helper which is when given a struct device returns the corresponding struct pci_dev which this device is a part of. Because of the header cross-dependencies, e.g. we need both struct pci_dev and struct arch_pci_dev at the same time, this cannot be done with

[PATCH 00/11] PCI devices passthrough on Arm, part 2

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Hi, all! This is an assorted series of patches which aim is to make some further basis for PCI passthrough on Arm support. The series continues the work published earlier by Arm [1] and adds new helpers and clears the way for vPCI changes which will follow. Thank

[PATCH 01/11] xen/arm: Add new device type for PCI

2021-09-03 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Add new device type (DEV_PCI) to distinguish PCI devices from platform DT devices, so some drivers, like IOMMU, can handle PCI devices differently. While at it fix dev_is_dt macro. Signed-off-by: Oleksandr Andrushchenko --- xen/include/asm-arm/device.h | 6

Re: [PATCH RFC] vPCI: account for hidden devices in modify_bars()

2021-08-31 Thread Oleksandr Andrushchenko
On 31.08.21 11:35, Jan Beulich wrote: On 31.08.2021 10:14, Oleksandr Andrushchenko wrote: On 31.08.21 11:05, Jan Beulich wrote: On 31.08.2021 09:56, Oleksandr Andrushchenko wrote: On 31.08.21 10:47, Jan Beulich wrote: On 31.08.2021 09:06, Oleksandr Andrushchenko wrote: On 31.08.21 09:51

Re: [PATCH RFC] vPCI: account for hidden devices in modify_bars()

2021-08-31 Thread Oleksandr Andrushchenko
On 31.08.21 11:05, Jan Beulich wrote: On 31.08.2021 09:56, Oleksandr Andrushchenko wrote: On 31.08.21 10:47, Jan Beulich wrote: On 31.08.2021 09:06, Oleksandr Andrushchenko wrote: On 31.08.21 09:51, Jan Beulich wrote: On 31.08.2021 07:35, Oleksandr Andrushchenko wrote: On 30.08.21 16:04

Re: [PATCH RFC] vPCI: account for hidden devices in modify_bars()

2021-08-31 Thread Oleksandr Andrushchenko
On 31.08.21 10:47, Jan Beulich wrote: On 31.08.2021 09:06, Oleksandr Andrushchenko wrote: On 31.08.21 09:51, Jan Beulich wrote: On 31.08.2021 07:35, Oleksandr Andrushchenko wrote: Hello, Jan! On 30.08.21 16:04, Jan Beulich wrote: Hidden devices (e.g. an add-in PCI serial card used for

Re: [PATCH RFC] vPCI: account for hidden devices in modify_bars()

2021-08-31 Thread Oleksandr Andrushchenko
On 31.08.21 09:51, Jan Beulich wrote: On 31.08.2021 07:35, Oleksandr Andrushchenko wrote: Hello, Jan! On 30.08.21 16:04, Jan Beulich wrote: Hidden devices (e.g. an add-in PCI serial card used for Xen's serial console) are associated with DomXEN, not Dom0. This means that while lookin

Re: [PATCH RFC] vPCI: account for hidden devices in modify_bars()

2021-08-30 Thread Oleksandr Andrushchenko
Hello, Jan! On 30.08.21 16:04, Jan Beulich wrote: Hidden devices (e.g. an add-in PCI serial card used for Xen's serial console) are associated with DomXEN, not Dom0. This means that while looking for overlapping BARs such devices cannot be found on Dom0's list of devices; DomXEN's list also need

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

2021-08-24 Thread Oleksandr Andrushchenko
Hi, Jan! On 24.08.21 19:09, Jan Beulich wrote: On 19.08.2021 14:02, Rahul Singh wrote: --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -767,6 +767,13 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, else iommu_enable_device(pdev); +#ifdef CONFIG_ARM

Re: [PATCH] ns16550: Properly gate Exar PCIe UART cards support

2021-08-20 Thread Oleksandr Andrushchenko
On 20.08.21 15:07, Jan Beulich wrote: On 20.08.2021 13:54, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This fixes Arm build which doesn't have ns16550 PCI support. ns16550.c:313:5: error: implicit declaration of function 'enable_exar_enhanced_bits' [-

[PATCH] ns16550: Properly gate Exar PCIe UART cards support

2021-08-20 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko This fixes Arm build which doesn't have ns16550 PCI support. ns16550.c:313:5: error: implicit declaration of function 'enable_exar_enhanced_bits' [-Werror=implicit-function-declaration] 313 | enable_exar_enh

[PATCH v2] xen/arm: smmu: Set/clear IOMMU domain for device

2021-08-17 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko When a device is assigned/de-assigned it is required to properly set IOMMU domain used to protect the device. This assignment was missing, thus it was not possible to de-assign the device: (XEN) Deassigning device :03:00.0 from dom2 (XEN) smmu: :03:00.0

Re: [PATCH] xen/arm: smmu: Set/clear IOMMU domain for device

2021-08-17 Thread Oleksandr Andrushchenko
Hi, Julien! On 17.08.21 20:21, Julien Grall wrote: Hi Oleksandr, Apologies for the late answer. On 11/08/2021 14:03, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko When a device is assigned/de-assigned it is required to properly set IOMMU domain used to protect the device

[PATCH] xen/arm: smmu: Set/clear IOMMU domain for device

2021-08-11 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko When a device is assigned/de-assigned it is required to properly set IOMMU domain used to protect the device. This assignment was missing, thus it was not possible to de-assign the device: (XEN) Deassigning device :03:00.0 from dom2 (XEN) smmu: :03:00.0

Re: [PATCH v3 1/3] xen/blkfront: read response from backend only once

2021-08-03 Thread Oleksandr Andrushchenko
On 02.08.21 22:26, Julien Grall wrote: > Hi, > > On 02/08/2021 15:06, Oleksandr Andrushchenko wrote: >> On 30.07.21 13:38, Juergen Gross wrote: >>> In order to avoid problems in case the backend is modifying a response >>> on the ring page while the frontend h

Re: [PATCH v3 1/3] xen/blkfront: read response from backend only once

2021-08-02 Thread Oleksandr Andrushchenko
Hi, Juergen! On 30.07.21 13:38, Juergen Gross wrote: > In order to avoid problems in case the backend is modifying a response > on the ring page while the frontend has already seen it, just read the > response into a local buffer in one go and then operate on that buffer > only. > > Signed-off-by:

Re: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues)

2021-06-18 Thread Oleksandr Andrushchenko
Hi, all! What do we need in order to move on on this? It seems this can be good to have for many use-cases around Thank you, Oleksandr On 20.05.21 19:21, Stefano Stabellini wrote: On Thu, 20 May 2021, Julien Grall wrote: On 20/05/2021 00:25, Stefano Stabellini wrote: On Sat, 15 May 2021, J

Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?

2021-06-10 Thread Oleksandr Andrushchenko
On 11.06.21 09:45, Jan Beulich wrote: > On 10.06.2021 17:33, Oleksandr Andrushchenko wrote: >> On 10.06.21 17:10, Roger Pau Monné wrote: >>> On Thu, Jun 10, 2021 at 10:01:16AM +, Oleksandr Andrushchenko wrote: >>>> On 10.06.21 10:54, Roger Pau Monné wrote: >&

Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?

2021-06-10 Thread Oleksandr Andrushchenko
On 10.06.21 17:10, Roger Pau Monné wrote: > On Thu, Jun 10, 2021 at 10:01:16AM +0000, Oleksandr Andrushchenko wrote: >> Hello, Roger! >> >> On 10.06.21 10:54, Roger Pau Monné wrote: >>> On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote: >>

Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?

2021-06-10 Thread Oleksandr Andrushchenko
On 10.06.21 15:02, Jan Beulich wrote: > On 10.06.2021 13:45, Oleksandr Andrushchenko wrote: >> Hi, Jan! >> >> On 10.06.21 13:48, Jan Beulich wrote: >>> On 10.06.2021 12:01, Oleksandr Andrushchenko wrote: >>>> On 10.06.21 10:54, Roger Pau Monné wrote: >

Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?

2021-06-10 Thread Oleksandr Andrushchenko
Hi, Jan! On 10.06.21 13:48, Jan Beulich wrote: > On 10.06.2021 12:01, Oleksandr Andrushchenko wrote: >> On 10.06.21 10:54, Roger Pau Monné wrote: >>> OTOH if we properly trap accesses to the SR-IOV capability (like it >>> was proposed in [1] from your references) w

Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?

2021-06-10 Thread Oleksandr Andrushchenko
Hello, Roger! On 10.06.21 10:54, Roger Pau Monné wrote: > On Fri, Jun 04, 2021 at 06:37:27AM +0000, Oleksandr Andrushchenko wrote: >> Hi, all! >> >> While working on PCI SR-IOV support for ARM I started porting [1] on top >> of current PCI on ARM support [2]. The ques

Re: [PATCH 2/2] libgnttab: Add support for Linux dma-buf offset

2021-06-08 Thread Oleksandr Andrushchenko
(not so great) Thank you in advance, Oleksandr On 01.10.20 09:35, Oleksandr Andrushchenko wrote: > Hi, > > On 9/28/20 6:20 PM, Ian Jackson wrote: >> Oleksandr Andrushchenko writes ("[PATCH 2/2] libgnttab: Add support for >> Linux dma-buf offset"): >>&g

SR-IOV: do we need to virtualize in Xen or rely on Dom0?

2021-06-03 Thread Oleksandr Andrushchenko
Hi, all! While working on PCI SR-IOV support for ARM I started porting [1] on top of current PCI on ARM support [2]. The question I have for this series is if we really need emulating SR-IOV code in Xen? I have implemented a PoC for SR-IOV on ARM [3] (please see the top 2 patches) and it "works

Re: [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default

2021-05-21 Thread Oleksandr Andrushchenko
On 5/21/21 12:09 PM, Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Oleksandr Andrushchenko

Re: Hand over of the Xen shared info page

2021-05-20 Thread Oleksandr Andrushchenko
Hi, On 5/20/21 12:46 PM, Julien Grall wrote: > > > On 20/05/2021 06:21, Oleksandr Andrushchenko wrote: >> Hi, all! > > Hi, > > >> On 5/20/21 2:11 AM, Stefano Stabellini wrote: >>> On Wed, 19 May 2021, Julien Grall wrote: >>>> On 14/05/20

Re: Hand over of the Xen shared info page

2021-05-19 Thread Oleksandr Andrushchenko
Hi, all! On 5/20/21 2:11 AM, Stefano Stabellini wrote: > On Wed, 19 May 2021, Julien Grall wrote: >> On 14/05/2021 10:50, Anastasiia Lukianenko wrote: >>> Hi Julien! >> Hello, >> >>> On Thu, 2021-05-13 at 09:37 +0100, Julien Grall wrote: On 13/05/2021 09:03, Anastasiia Lukianenko wrote:

Re: [PATCH] drivers: gpu: drm: xen_drm_front_drm_info is declared twice

2021-03-25 Thread Oleksandr Andrushchenko
Hi, Daniel! On 3/25/21 11:16 AM, Daniel Vetter wrote: > On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko > wrote: >> Hi, >> >> On 3/25/21 8:19 AM, Wan Jiabing wrote: >>> struct xen_drm_front_drm_info has been declared. >>> Remove the duplicate. &g

Re: [PATCH] drivers: gpu: drm: xen_drm_front_drm_info is declared twice

2021-03-25 Thread Oleksandr Andrushchenko
Hi, On 3/25/21 8:19 AM, Wan Jiabing wrote: > struct xen_drm_front_drm_info has been declared. > Remove the duplicate. > > Signed-off-by: Wan Jiabing Thank you for the patch, Reviewed-by: Oleksandr Andrushchenko Will apply to drm-misc-next-fixes Thank you, Oleksandr > ---

Re: [PATCH] gpu/xen: Fix a use after free in xen_drm_drv_init

2021-03-24 Thread Oleksandr Andrushchenko
iled and still free the drm_info. > Second sets front_info->drm_info to NULL to avoid uaf. > > Signed-off-by: Lv Yunlong Thank you for the patch, Reviewed-by: Oleksandr Andrushchenko Will apply to drm-misc-next-fixes Thank you, Oleksandr > --- > drivers/gpu/drm/xen/xen_d

Re: [PATCH] drm/xen: adjust Kconfig

2021-02-28 Thread Oleksandr Andrushchenko
On 2/24/21 6:17 PM, Daniel Vetter wrote: > On Wed, Feb 24, 2021 at 8:55 AM Oleksandr Andrushchenko > wrote: >> Hello, Jan! >> >> On 2/23/21 6:41 PM, Jan Beulich wrote: >>> By having selected DRM_XEN, I was assuming I would build the frontend >>> driv

Re: [PATCH] drm/xen: adjust Kconfig

2021-02-23 Thread Oleksandr Andrushchenko
"depends on" to the other, real option, and "select"ing > the dummy one. > > Signed-off-by: Jan Beulich Reviewed-by: Oleksandr Andrushchenko > --- a/drivers/gpu/drm/xen/Kconfig > +++ b/drivers/gpu/drm/xen/Kconfig > @@ -1,15 +1,11 @@ > # SPDX-License-Ide

Re: [PATCH] xen-front-pgdir-shbuf: don't record wrong grant handle upon error

2021-02-23 Thread Oleksandr Andrushchenko
Hello, Jan! On 2/23/21 6:26 PM, Jan Beulich wrote: > In order for subsequent unmapping to not mistakenly unmap handle 0, > record a perceived always-invalid one instead. > > Signed-off-by: Jan Beulich > Reviewed-by: Juergen Gross Reviewed-by: Oleksandr Andrushchenko

Re: [PATCH v7 0/7] xl / libxl: named PCI pass-through devices

2021-01-13 Thread Oleksandr Andrushchenko
Hi, Wei! Is this series good to go? Could you please tell if it breaks anything? Thank you in advance, Oleksandr On 1/5/21 7:46 PM, Paul Durrant wrote: > From: Paul Durrant > > These are re-worked versions of the remaining patches from v6 of the series > that were reverted by commit ac6a0af387

Re: PVH mode PCI passthrough status

2020-12-29 Thread Oleksandr Andrushchenko
Hi, all On 12/29/20 8:32 PM, Roger Pau Monné wrote: > On Tue, Dec 29, 2020 at 05:01:50PM +, tosher 1 wrote: >> Hi Roger, >> >>> I think you meant PVH mode in the sentence above instead of PVM? >> Sorry, that was a typo. I meant PVH. >> >>> Arm folks are working on using vPCI for domUs, which c

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-12-07 Thread Oleksandr Andrushchenko
On 12/7/20 11:28 AM, Jan Beulich wrote: > On 07.12.2020 10:11, Oleksandr Andrushchenko wrote: >> On 12/7/20 10:48 AM, Jan Beulich wrote: >>> On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 4:51 PM, Jan Beulich wrote: >>>>> On 13

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-12-07 Thread Oleksandr Andrushchenko
On 12/7/20 10:48 AM, Jan Beulich wrote: > On 04.12.2020 15:38, Oleksandr Andrushchenko wrote: >> On 11/13/20 4:51 PM, Jan Beulich wrote: >>> On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 4:38 PM, Jan Beulich wrote: >>>>> On 13

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-12-04 Thread Oleksandr Andrushchenko
Hi, Jan! On 11/13/20 4:51 PM, Jan Beulich wrote: > On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: >> On 11/13/20 4:38 PM, Jan Beulich wrote: >>> On 13.11.2020 15:32, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 4:23 PM, Jan Beulich wrote: >>>>&g

Re: [PATCH v4 03/23] libxl: Make sure devices added by pci-attach are reflected in the config

2020-12-03 Thread Oleksandr Andrushchenko
On 12/3/20 3:17 PM, Paul Durrant wrote: >> -Original Message- >> From: Oleksandr Andrushchenko >> Sent: 01 December 2020 13:12 >> To: Paul Durrant ; xen-devel@lists.xenproject.org >> Cc: Paul Durrant ; Ian Jackson ; >> Wei Liu ; >> Anthony PERA

Re: [PATCH v4 14/23] docs/man: extract documentation of PCI_SPEC_STRING from the xl.cfg manpage...

2020-12-01 Thread Oleksandr Andrushchenko
A subsequent patch > will improve the documentation, once it is in its new location. > > Signed-off-by: Paul Durrant Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr > --- > Cc: Ian Jackson > Cc: Wei Liu > --- > docs/man/xl-pci-configuration.5.pod | 78 > +

Re: [PATCH v4 13/23] libxl: use COMPARE_PCI() macro is_pci_in_array()...

2020-12-01 Thread Oleksandr Andrushchenko
uivalent, and also modifies it to return a > 'bool' rather than an 'int'. > > NOTE: The COMPARE_PCI() macro is also fixed to include the 'domain' in its > comparison, which should always have been the case. > > Signed-off-by: Paul Durrant Review

Re: [PATCH v4 12/23] libxl: add libxl_device_pci_assignable_list_free()...

2020-12-01 Thread Oleksandr Andrushchenko
ure it is used everywhere and > also modifies libxl_device_pci_assignable_list() to initialize list > entries rather than just zeroing them. > > Signed-off-by: Paul Durrant Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr > --- > Cc: Ian Jackson > Cc: Wei Liu

Re: [PATCH v4 11/23] libxl: make sure callers of libxl_device_pci_list() free the list after use

2020-12-01 Thread Oleksandr Andrushchenko
x27; and 'pci_remove_state' (and also making > sure these are properly disposed at the end of the operations) rather > than keeping pointers to the structures returned by libxl_device_pci_list(). > > Signed-off-by: Paul Durrant Reviewed-by: Oleksandr Andrushchenko Thank you

Re: [PATCH v4 10/23] libxl: remove get_all_assigned_devices() from libxl_pci.c

2020-12-01 Thread Oleksandr Andrushchenko
pci_info_xs_read() earlier in libxl_pci.c. To keep related functions >together, the rest of the pci_info_xs_XXX() functions are moved too. > > Signed-off-by: Paul Durrant Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr > --- > Cc: Ian Jackson > Cc:

Re: [PATCH v4 09/23] libxl: remove unnecessary check from libxl__device_pci_add()

2020-12-01 Thread Oleksandr Andrushchenko
ist() and hence the > libxl_pci_assignable() test would have already failed. > > Signed-off-by: Paul Durrant Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr > --- > Cc: Ian Jackson > Cc: Wei Liu > --- > tools/libs/light/libxl_pci.c | 16 +---

Re: [PATCH v4 08/23] libxl: generalise 'driver_path' xenstore access functions in libxl_pci.c

2020-12-01 Thread Oleksandr Andrushchenko
t. Subsequent patches will invoke them to > access other nodes. > > NOTE: Because functions will have a broader use (other than storing a >driver path in lieu of pciback) the base xenstore path is also >changed from '/libxl/pciback' to '/libxl/pci'

Re: [PATCH v4 07/23] libxl: stop using aodev->device_config in libxl__device_pci_add()...

2020-12-01 Thread Oleksandr Andrushchenko
o be dropped from > do_pci_add(). > > NOTE: This patch also changes the type of the 'pci_domid' field in >'pci_add_state' from 'int' to 'libxl_domid' which is more appropriate >given what the field is used for. > > Signed

Re: [PATCH v4 06/23] libxl: remove extraneous arguments to do_pci_remove() in libxl_pci.c

2020-12-01 Thread Oleksandr Andrushchenko
Hi, Paul! On 11/24/20 10:01 AM, Paul Durrant wrote: > From: Paul Durrant > > Both 'domid' and 'pci' are available in 'pci_remove_state' so there is no > need to also pass them as separate arguments. > > Signed-off-by: Paul Durrant Reviewed-by:

Re: [PATCH v4 05/23] libxl: s/detatched/detached in libxl_pci.c

2020-12-01 Thread Oleksandr Andrushchenko
Hi, Paul! On 11/24/20 10:01 AM, Paul Durrant wrote: From: Paul Durrant Simply spelling correction. Purely cosmetic fix. Signed-off-by: Paul Durrant Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr --- Cc: Ian Jackson Cc: Wei Liu --- tools/libs/light/libxl_pci.c | 22

Re: [PATCH v4 04/23] libxl: add/recover 'rdm_policy' to/from PCI backend in xenstore

2020-12-01 Thread Oleksandr Andrushchenko
Hi, Paul! On 11/24/20 10:01 AM, Paul Durrant wrote: > From: Paul Durrant > > Other parameters, such as 'msitranslate' and 'permissive' are dealt with > but 'rdm_policy' appears to be have been completely missed. > > Signed-off-by: Paul Durrant

Re: [PATCH v4 03/23] libxl: Make sure devices added by pci-attach are reflected in the config

2020-12-01 Thread Oleksandr Andrushchenko
Hi, Paul! On 11/24/20 10:01 AM, Paul Durrant wrote: > From: Paul Durrant > > Currently libxl__device_pci_add_xenstore() is broken in that does not > update the domain's configuration for the first device added (which causes > creation of the overall backend area in xenstore). This can be easily o

Re: [PATCH v4 02/23] libxl: make libxl__device_list() work correctly for LIBXL__DEVICE_KIND_PCI...

2020-12-01 Thread Oleksandr Andrushchenko
e libxl__device_list() work correctly, this patch removes the > open-coded libxl_pci_device_pci_list() in favour of an evaluation of the > LIBXL_DEFINE_DEVICE_LIST() macro. This has the side-effect of also defining > libxl_pci_device_pci_list_free() which will be used in subsequent patches. >

Re: [PATCH v4 01/23] xl / libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X

2020-12-01 Thread Oleksandr Andrushchenko
{ > +while (fscanf(f, "%x:%x:%x.%d\n", &dom, &bus, &dev, &func)==4) { So, then you can probably put spaces around "4" if touching this line > +if (dom == pci->domain > +&& bus == pci->bus > +&& dev == pci->dev > +&& func == pci->func) { > rc = 1; > goto out; > } > @@ -649,7 +649,7 @@ out: > return rc; > } > Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr

Re: [PATCH v2 00/24] xl / libxl: named PCI pass-through devices

2020-11-16 Thread Oleksandr Andrushchenko
s/ocaml/libs/xl/xenlight_stubs.c | 19 +- > tools/xl/xl_cmdtable.c | 16 +- > tools/xl/xl_parse.c | 28 +- > tools/xl/xl_pci.c | 159 ++-- > tools/xl/xl_sxp.c| 12 +- > 19 files changed, 1308 inserti

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 4:51 PM, Jan Beulich wrote: > On 13.11.2020 15:44, Oleksandr Andrushchenko wrote: >> On 11/13/20 4:38 PM, Jan Beulich wrote: >>> On 13.11.2020 15:32, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 4:23 PM, Jan Beulich wrote: >>>>> E

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 4:38 PM, Jan Beulich wrote: > On 13.11.2020 15:32, Oleksandr Andrushchenko wrote: >> On 11/13/20 4:23 PM, Jan Beulich wrote: >>> On 13.11.2020 13:41, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 1:35 PM, Jan Beulich wrote: >>>>> On 13

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 4:23 PM, Jan Beulich wrote: > On 13.11.2020 13:41, Oleksandr Andrushchenko wrote: >> On 11/13/20 1:35 PM, Jan Beulich wrote: >>> On 13.11.2020 12:02, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 12:50 PM, Jan Beulich wrote: >>>>> On 13

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 1:35 PM, Jan Beulich wrote: > On 13.11.2020 12:02, Oleksandr Andrushchenko wrote: >> On 11/13/20 12:50 PM, Jan Beulich wrote: >>> On 13.11.2020 11:46, Oleksandr Andrushchenko wrote: >>>> On 11/13/20 12:25 PM, Jan Beulich wrote: >>>>> On 13

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 12:50 PM, Jan Beulich wrote: > On 13.11.2020 11:46, Oleksandr Andrushchenko wrote: >> On 11/13/20 12:25 PM, Jan Beulich wrote: >>> On 13.11.2020 07:32, Oleksandr Andrushchenko wrote: >>>> On 11/12/20 4:46 PM, Roger Pau Monné wrote: >>>>

Re: [PATCH 08/10] vpci/arm: Allow updating BAR's header for non-ECAM bridges

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 12:47 PM, Jan Beulich wrote: > On 13.11.2020 11:39, Oleksandr Andrushchenko wrote: >> On 11/13/20 12:29 PM, Jan Beulich wrote: >>> On 09.11.2020 13:50, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr Andrushchenko >>>> >>>> No

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 12:25 PM, Jan Beulich wrote: > On 13.11.2020 07:32, Oleksandr Andrushchenko wrote: >> On 11/12/20 4:46 PM, Roger Pau Monné wrote: >>> On Thu, Nov 12, 2020 at 01:16:10PM +, Oleksandr Andrushchenko wrote: >>>> On 11/12/20 11:40 AM, Roger Pau Monné wro

Re: [PATCH 08/10] vpci/arm: Allow updating BAR's header for non-ECAM bridges

2020-11-13 Thread Oleksandr Andrushchenko
On 11/13/20 12:29 PM, Jan Beulich wrote: > On 09.11.2020 13:50, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Non-ECAM host bridges in hwdom go directly to PCI config space, >> not through vpci (they use their specific method for accessin

Re: [PATCH 09/10] vpci/rcar: Implement vPCI.update_bar_header callback

2020-11-12 Thread Oleksandr Andrushchenko
On 11/12/20 12:00 PM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:30PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Update hardware domain's BAR header as R-Car Gen3 is a non-ECAM host >> controller, so vPCI MMIO hand

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-12 Thread Oleksandr Andrushchenko
On 11/13/20 8:32 AM, Oleksandr Andrushchenko wrote: > > On 11/12/20 4:46 PM, Roger Pau Monné wrote: >> On Thu, Nov 12, 2020 at 01:16:10PM +0000, Oleksandr Andrushchenko wrote: >>> On 11/12/20 11:40 AM, Roger Pau Monné wrote: >>>> On Mon, Nov 09, 2020 at 02:50:27

Re: [PATCH 08/10] vpci/arm: Allow updating BAR's header for non-ECAM bridges

2020-11-12 Thread Oleksandr Andrushchenko
On 11/12/20 11:56 AM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:29PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Non-ECAM host bridges in hwdom go directly to PCI config space, >> not through vpci (they use their specif

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-12 Thread Oleksandr Andrushchenko
On 11/12/20 4:46 PM, Roger Pau Monné wrote: > On Thu, Nov 12, 2020 at 01:16:10PM +0000, Oleksandr Andrushchenko wrote: >> On 11/12/20 11:40 AM, Roger Pau Monné wrote: >>> On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr An

Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

2020-11-12 Thread Oleksandr Andrushchenko
On 11/12/20 11:40 AM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:27PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> At the moment there is an identity mapping between how a guest sees its >> BARs and how they are programmed in

Re: [PATCH 04/10] [WORKAROUND] xen/arm: Update hwdom's p2m to trap ECAM space

2020-11-12 Thread Oleksandr Andrushchenko
On 11/11/20 4:44 PM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:25PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Host bridge controller's ECAM space is mapped into Domain-0's p2m, >> thus it is not possible to tra

Re: [PATCH 02/10] arm/pci: Maintain PCI assignable list

2020-11-12 Thread Oleksandr Andrushchenko
On 11/11/20 4:54 PM, Jan Beulich wrote: > On 09.11.2020 13:50, Oleksandr Andrushchenko wrote: >> --- a/xen/drivers/passthrough/pci.c >> +++ b/xen/drivers/passthrough/pci.c >> @@ -879,6 +879,43 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn) >> return r

Re: [PATCH 02/10] arm/pci: Maintain PCI assignable list

2020-11-11 Thread Oleksandr Andrushchenko
On 11/11/20 5:25 PM, Jan Beulich wrote: > On 11.11.2020 16:13, Oleksandr Andrushchenko wrote: >> On 11/11/20 5:03 PM, Roger Pau Monné wrote: >>> On Wed, Nov 11, 2020 at 02:38:47PM +, Oleksandr Andrushchenko wrote: >>>> On 11/11/20 3:53 PM, Roger Pau Monné wrote:

Re: [PATCH 02/10] arm/pci: Maintain PCI assignable list

2020-11-11 Thread Oleksandr Andrushchenko
On 11/11/20 5:03 PM, Roger Pau Monné wrote: > On Wed, Nov 11, 2020 at 02:38:47PM +0000, Oleksandr Andrushchenko wrote: >> On 11/11/20 3:53 PM, Roger Pau Monné wrote: >>> On Mon, Nov 09, 2020 at 02:50:23PM +0200, Oleksandr Andrushchenko wrote: >>>> From: Oleksand

Re: [PATCH 03/10] xen/arm: Setup MMIO range trap handlers for hardware domain

2020-11-11 Thread Oleksandr Andrushchenko
On 11/11/20 4:39 PM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:24PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> In order vPCI to work it needs all access to PCI configuration space >> access to be synchronized among all ent

Re: [PATCH 02/10] arm/pci: Maintain PCI assignable list

2020-11-11 Thread Oleksandr Andrushchenko
On 11/11/20 3:53 PM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:23PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> The original code depends on pciback to manage assignable device list. >> The functionality which is impleme

Re: [SUSPECTED SPAM][PATCH 01/10] pci/pvh: Allow PCI toolstack code run with PVH domains on ARM

2020-11-11 Thread Oleksandr Andrushchenko
On 11/11/20 3:55 PM, Roger Pau Monné wrote: > On Wed, Nov 11, 2020 at 01:10:01PM +0000, Oleksandr Andrushchenko wrote: >> On 11/11/20 2:31 PM, Roger Pau Monné wrote: >>> On Mon, Nov 09, 2020 at 02:50:22PM +0200, Oleksandr Andrushchenko wrote: >>>>

Re: [SUSPECTED SPAM][PATCH 01/10] pci/pvh: Allow PCI toolstack code run with PVH domains on ARM

2020-11-11 Thread Oleksandr Andrushchenko
On 11/11/20 2:31 PM, Roger Pau Monné wrote: > On Mon, Nov 09, 2020 at 02:50:22PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> According to https://wiki.xenproject.org/wiki/Linux_PVH: >> >> Items not supported by PVH >&g

[PATCH 10/10] [HACK] vpci/rcar: Make vPCI know DomD is hardware domain

2020-11-09 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/header.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index 1f326c894d16..d5738ecca93d 100644 --- a/xen

[PATCH 08/10] vpci/arm: Allow updating BAR's header for non-ECAM bridges

2020-11-09 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko Non-ECAM host bridges in hwdom go directly to PCI config space, not through vpci (they use their specific method for accessing PCI configuration, e.g. dedicated registers etc.). Thus hwdom's vpci BARs are never updated via vPCI MMIO handlers, so implem

<    2   3   4   5   6   7   8   9   10   11   >