Re: [RFC v3 01/21] iommu: Introduce set_pasid_table API

Hi Jean-Philippe, On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote: > On 08/01/2019 10:26, Eric Auger wrote: >> From: Jacob Pan >> >> In virtualization use case, when a guest is assigned >> a PCI host device, protected by a virtual IOMMU on a guest, >> the physical IOMMU must be programmed to be c

Re: [RFC v3 01/21] iommu: Introduce set_pasid_table API

Hi Jean-Philippe, On 1/25/19 9:39 AM, Auger Eric wrote: > Hi Jean-Philippe, > > On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote: >> On 08/01/2019 10:26, Eric Auger wrote: >>> From: Jacob Pan >>> >>> In virtualization use case, when a guest is assigned >>> a PCI host device, protected by a virtua

Re: [RFC v3 01/21] iommu: Introduce set_pasid_table API

Hi Alex, On 1/11/19 7:43 PM, Alex Williamson wrote: > On Tue, 8 Jan 2019 11:26:13 +0100 > Eric Auger wrote: > >> From: Jacob Pan >> >> In virtualization use case, when a guest is assigned >> a PCI host device, protected by a virtual IOMMU on a guest, >> the physical IOMMU must be programmed to

Re: [PATCH 1/3] PCI: iproc: Add feature to set order mode

Hi Bjorn, Thank you, Please see my comments below inline. On Fri, Jan 25, 2019 at 1:01 AM Bjorn Helgaas wrote: > > On Thu, Jan 24, 2019 at 02:10:18PM +0530, Srinath Mannam wrote: > > On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote: > > > On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Man

[PATCH v3 3/3] PCI: iproc: Add dma reserve resources to host

IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. Inbound address of host accessed by PCIe devices will not be translated before it c

[PATCH v3 1/3] PCI: Add dma-resv window list

Add a dma_resv parameter in PCI host bridge structure to hold resource entries list of memory regions for which IOVAs have to reserve. PCIe host driver will add resource entries to this list based on its requirements. Few inbound address ranges can't be allowed by few PCIe host, so those address r

[PATCH v3 2/3] iommu/dma: Reserve IOVA for PCI host reserve address list

PCI host bridge has list of resource entries contain address ranges for which IOVA address mapping has to be reserve. These address ranges are the address holes in dma-ranges DT property. It is similar to PCI IO resources address ranges reserving in IOMMU for each EP connected to host bridge. Sig

[PATCH v3 0/3] PCIe Host request to reserve IOVA

Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those

Re: [RFC v3 01/21] iommu: Introduce set_pasid_table API

On 25/01/2019 08:55, Auger Eric wrote: > Hi Jean-Philippe, > > On 1/25/19 9:39 AM, Auger Eric wrote: >> Hi Jean-Philippe, >> >> On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote: >>> On 08/01/2019 10:26, Eric Auger wrote: From: Jacob Pan In virtualization use case, when a guest is as

Re: [PATCH] dcdbas: Fix Intel-IOMMU domain allocation failure

On Fri, Jan 25, 2019 at 3:50 AM Szabolcs Fruhwald wrote: First of all, please do not top post! > I took a quick look at arch_setup_pdev_archdata(), overridden it in > dcdbas.c and it works well (despite it's being called twice, since > it's called from platform_device_alloc and platform_device_r

Re: [PATCH] dcdbas: Fix Intel-IOMMU domain allocation failure

On 25/01/2019 11:58, Andy Shevchenko wrote: On Fri, Jan 25, 2019 at 3:50 AM Szabolcs Fruhwald wrote: First of all, please do not top post! I took a quick look at arch_setup_pdev_archdata(), overridden it in dcdbas.c and it works well (despite it's being called twice, since it's called from pl

Re: use generic DMA mapping code in powerpc V4

Next step just with the first patch: 5c532d07c2f3c3972104de505d06b8d85f403f06 (use powerpc zone selection) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6-debug a git checkout 5c532d07c2f3c3972104de505d06b8d85f403f06 Link to the Git: http://git.infradead.org/users/hch/

Re: [PATCH 1/3] PCI: iproc: Add feature to set order mode

On Fri, Jan 25, 2019 at 03:13:38PM +0530, Srinath Mannam wrote: > On Fri, Jan 25, 2019 at 1:01 AM Bjorn Helgaas wrote: > > On Thu, Jan 24, 2019 at 02:10:18PM +0530, Srinath Mannam wrote: > > > On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote: > > > > On Fri, Jan 18, 2019 at 09:53:21AM +0530, S

Re: [RFC v3 02/21] iommu: Introduce cache_invalidate API

Hi Alex, On 1/11/19 10:30 PM, Alex Williamson wrote: > On Tue, 8 Jan 2019 11:26:14 +0100 > Eric Auger wrote: > >> From: "Liu, Yi L" >> >> In any virtualization use case, when the first translation stage >> is "owned" by the guest OS, the host IOMMU driver has no knowledge >> of caching structu

Re: [RFC v3 03/21] iommu: Introduce bind_guest_msi

Hi Alex, On 1/11/19 11:44 PM, Alex Williamson wrote: > On Tue, 8 Jan 2019 11:26:15 +0100 > Eric Auger wrote: > >> On ARM, MSI are translated by the SMMU. An IOVA is allocated >> for each MSI doorbell. If both the host and the guest are exposed >> with SMMUs, we end up with 2 different IOVAs allo

Re: [RFC v3 03/21] iommu: Introduce bind_guest_msi

Hi Alex, On 1/11/19 11:44 PM, Alex Williamson wrote: > On Tue, 8 Jan 2019 11:26:15 +0100 > Eric Auger wrote: > >> On ARM, MSI are translated by the SMMU. An IOVA is allocated >> for each MSI doorbell. If both the host and the guest are exposed >> with SMMUs, we end up with 2 different IOVAs all

Re: [RFC v3 09/21] iommu/smmuv3: Get prepared for nested stage support

On 08/01/2019 10:26, Eric Auger wrote: To allow nested stage support, we need to store both stage 1 and stage 2 configurations (and remove the former union). arm_smmu_write_strtab_ent() is modified to write both stage fields in the STE. We add a nested_bypass field to the S1 configuration as th