Re: [PATCH 2/9] Move dma_ops from archdata into struct device

On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > transfer data between memory and PCIe adapter. Because of performance > reasons it is important that the CPU cache is not flushed when such > drivers transfer

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > transfer data between memory and PCIe adapter. Because of performance > reasons it is important that the CPU cache is not flushed when such > drivers transfer

Re: [PATCH v7 2/7] perf/amd/iommu: Modify functions to query max banks and counters

On 1/10/17 21:43, Joerg Roedel wrote: On Mon, Jan 09, 2017 at 09:33:42PM -0600, Suthikulpanit, Suravee wrote: +static struct amd_iommu *get_amd_iommu(uint idx) +{ + uint i = 0; + struct amd_iommu *iommu = NULL; + + for_each_iommu(iommu) { + if (i == idx) +

[PATCH 2/9] Move dma_ops from archdata into struct device

Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to transfer data between memory and PCIe adapter. Because of performance reasons it is important that the CPU cache is not flushed when such drivers transfer data. Make this possible by allowing these drivers to override the

Re: [PATCH v7 08/19] iommu: Implement reserved_regions iommu-group sysfs file

Hi Joerg, On 10/01/2017 18:14, Joerg Roedel wrote: > On Tue, Jan 10, 2017 at 05:20:34PM +0100, Auger Eric wrote: >> The /sys/kernel/iommu_groups/n directory seems to be removed before this >> gets called and this may produce a WARNING when devices get removed from >> the group. I intend to remove

[PATCH] iommu/arm-smmu-v3: limit use of 2-level stream tables

In the current arm-smmu-v3 driver, all smmus that support 2-level stream tables are being forced to use them. This is suboptimal for smmus that support fewer stream id bits than would fill in a single second level table. This patch limits the use of 2-level tables to smmus that both support the

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon wrote: > Hi Rob, > > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote: >> On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon wrote: >> > On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote: >> >> I'm

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

Hi Rob, On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote: > On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon wrote: > > On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote: > >> I'm not sure if the better solution then would be to have two fault > >> callbacks,

Re: [PATCH v7 08/19] iommu: Implement reserved_regions iommu-group sysfs file

On Tue, Jan 10, 2017 at 05:20:34PM +0100, Auger Eric wrote: > The /sys/kernel/iommu_groups/n directory seems to be removed before this > gets called and this may produce a WARNING when devices get removed from > the group. I intend to remove the call since I have the feeling > everything gets

Re: [PATCH v7 08/19] iommu: Implement reserved_regions iommu-group sysfs file

Hi Joerg, On 09/01/2017 14:45, Eric Auger wrote: > A new iommu-group sysfs attribute file is introduced. It contains > the list of reserved regions for the iommu-group. Each reserved > region is described on a separate line: > - first field is the start IOVA address, > - second is the end IOVA

Re: [PATCH v7 00/19] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi all, On 10/01/2017 15:09, Joerg Roedel wrote: > On Mon, Jan 09, 2017 at 01:45:51PM +, Eric Auger wrote: >> Eric Auger (17): >> iommu: Rename iommu_dm_regions into iommu_resv_regions >> iommu: Add a new type field in iommu_resv_region >> iommu: iommu_alloc_resv_region >> iommu: Only

Re: [PATCH v7 01/19] iommu/dma: Implement PCI allocation optimisation

On 09/01/17 13:45, Eric Auger wrote: > From: Robin Murphy > > Whilst PCI devices may have 64-bit DMA masks, they still benefit from > using 32-bit addresses wherever possible in order to avoid DAC (PCI) or > longer address packets (PCIe), which may incur a performance

Re: [PATCH v7 2/7] perf/amd/iommu: Modify functions to query max banks and counters

On Mon, Jan 09, 2017 at 09:33:42PM -0600, Suthikulpanit, Suravee wrote: > +static struct amd_iommu *get_amd_iommu(uint idx) > +{ > + uint i = 0; > + struct amd_iommu *iommu = NULL; > + > + for_each_iommu(iommu) { > + if (i == idx) > + break; > +

Re: [PATCH v7 19/19] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore

On Mon, Jan 09, 2017 at 01:46:10PM +, Eric Auger wrote: > IOMMU_CAP_INTR_REMAP has been advertised in arm-smmu(-v3) although > on ARM this property is not attached to the IOMMU but rather is > implemented in the MSI controller (GICv3 ITS). > > Now vfio_iommu_type1 checks MSI remapping

Re: [PATCH v7 12/19] iommu/arm-smmu-v3: Implement reserved region get/put callbacks

On Mon, Jan 09, 2017 at 01:46:03PM +, Eric Auger wrote: > iommu/arm-smmu: Implement reserved region get/put callbacks > > The get() populates the list with the MSI IOVA reserved window. > > At the moment an arbitray MSI IOVA window is set at 0x800 > of size 1MB. This will allow to report

Re: [PATCH v7 11/19] iommu/arm-smmu: Implement reserved region get/put callbacks

On Mon, Jan 09, 2017 at 01:46:02PM +, Eric Auger wrote: > The get() populates the list with the MSI IOVA reserved window. > > At the moment an arbitray MSI IOVA window is set at 0x800 > of size 1MB. This will allow to report those info in iommu-group > sysfs. > > Signed-off-by: Eric

Re: [PATCH v7 00/19] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

On Tue, Jan 10, 2017 at 03:09:24PM +0100, Joerg Roedel wrote: > On Mon, Jan 09, 2017 at 01:45:51PM +, Eric Auger wrote: > > Eric Auger (17): > > iommu: Rename iommu_dm_regions into iommu_resv_regions > > iommu: Add a new type field in iommu_resv_region > > iommu: iommu_alloc_resv_region

Re: [PATCH v7 00/19] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

On Mon, Jan 09, 2017 at 01:45:51PM +, Eric Auger wrote: > Eric Auger (17): > iommu: Rename iommu_dm_regions into iommu_resv_regions > iommu: Add a new type field in iommu_resv_region > iommu: iommu_alloc_resv_region > iommu: Only map direct mapped regions > iommu:

Re: [PATCH v2 0/4] Fixes for Exynos IOMMU driver

On Mon, Jan 09, 2017 at 01:03:52PM +0100, Marek Szyprowski wrote: > Marek Szyprowski (4): > iommu/exynos: Improve page fault debug message > iommu/exynos: Fix warnings from DMA-debug > iommu/exynos: Ensure that SYSMMU is added only once to its master > device > iommu/exynos: Properly

[RFC PATCH] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)

Enable the Extended Stream ID feature when available. This patch on top of series "[PATCH v7 00/19] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions" by Eric Auger allows to passthrough an external PCIe network card on a ThunderX server successfully. Without this patch that card

Re: [PATCH v7 16/19] irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP

Hi Eric, On 09/01/17 13:46, Eric Auger wrote: > The GICv3 ITS is MSI remapping capable. Let's advertise > this property so that VFIO passthrough can assess IRQ safety. > > Signed-off-by: Eric Auger > --- > drivers/irqchip/irq-gic-v3-its.c | 1 + > 1 file changed, 1

Re: [PATCH v7 15/19] irqdomain: irq_domain_check_msi_remap

On 09/01/17 13:46, Eric Auger wrote: > This new function checks whether all MSI irq domains > implement IRQ remapping. This is useful to understand > whether VFIO passthrough is safe with respect to interrupts. > > On ARM typically an MSI controller can sit downstream > to the IOMMU without

Re: [PATCH v7 13/19] irqdomain: Add irq domain MSI and MSI_REMAP flags

Hi Eric, On 09/01/17 13:46, Eric Auger wrote: > We introduce two new enum values for the irq domain flag: > - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to > an MSI domain > - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI > remapping capabilities. > > Those values