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

Hi Bharat, On 12/01/2017 04:59, Bharat Bhushan wrote: > > >> -Original Message- >> From: Eric Auger [mailto:eric.au...@redhat.com] >> Sent: Wednesday, January 11, 2017 3:12 PM >> To: eric.au...@redhat.com; eric.auger@gmail.com; >> christoffer.d...@linaro.org; marc.zyng...@arm.com; >>

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

On Wed, Jan 11, 2017 at 10:28:05PM +, Bart Van Assche wrote: > On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote: > > That's a big sign that your patch series needs work. Break it up into > > smaller pieces, it should be possible, which will make merges easier > > (well,

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

On 11.01.2017 13:19, Robin Murphy wrote: On 11/01/17 11:51, Tomasz Nowicki wrote: The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the workaround code partitions ASIDs and VMIDs by increasing

RE: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

> -Original Message- > From: Eric Auger [mailto:eric.au...@redhat.com] > Sent: Wednesday, January 11, 2017 3:12 PM > To: eric.au...@redhat.com; eric.auger@gmail.com; > christoffer.d...@linaro.org; marc.zyng...@arm.com; > robin.mur...@arm.com; alex.william...@redhat.com; >

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

On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote: > That's a big sign that your patch series needs work. Break it up into > smaller pieces, it should be possible, which will make merges easier > (well, different in a way.) Hello Greg, Can you have a look at the attached

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

On Wed, Jan 11, 2017 at 4:36 AM, Will Deacon wrote: > On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote: >> On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon wrote: >> > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote: >> >> Hmm, well we

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

On Wed, Jan 11, 2017 at 06:17:03PM +, Bart Van Assche wrote: > On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote: > > 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

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

On Wed, Jan 11, 2017 at 06:03:15PM +, Bart Van Assche wrote: > On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote: > > 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

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

From: Tomasz Nowicki Sent: Wednesday, January 11, 2017 3:51 AM To: will.dea...@arm.com; robin.mur...@arm.com; mark.rutl...@arm.com; j...@8bytes.org Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org;

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

On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote: > 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

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

On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote: > 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

Re: [PATCH v7 3/7] perf/amd/iommu: Modify IOMMU API to allow specifying IOMMU index

On Mon, Jan 09, 2017 at 09:33:43PM -0600, Suravee Suthikulpanit wrote: > The current amd_iommu_pc_get_set_reg_val() cannot support multi-IOMMU. multiple IOMMUs. > It is also confusing since it is trying to support set and get in > one

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

On 10/01/17 11:57, Aleksey Makarov wrote: > 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

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

On 11/01/17 11:51, Tomasz Nowicki wrote: > The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs > are unique across all SMMU instances on affected Cavium systems. > > Currently, the workaround code partitions ASIDs and VMIDs by increasing > global cavium_smmu_context_count

Re: [PATCH v7 1/7] perf/amd/iommu: Misc fix up perf_iommu_read

On Mon, Jan 09, 2017 at 09:33:41PM -0600, Suravee Suthikulpanit wrote: > This patch contains the following minor fixup: > * Fixed overflow handling since u64 delta would lose the MSB sign bit. Please explain.. afaict this actually introduces a bug. > diff --git a/arch/x86/events/amd/iommu.c

[PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the workaround code partitions ASIDs and VMIDs by increasing global cavium_smmu_context_count which in turn becomes the base ASID and VMID value

Re: [PATCH v7 1/7] perf/amd/iommu: Misc fix up perf_iommu_read

On Mon, Jan 09, 2017 at 09:33:41PM -0600, Suravee Suthikulpanit wrote: > This patch contains the following minor fixup: For the future: never say "this patch" in the commit message - just explain *why* the patch is needed. > * Fixed overflow handling since u64 delta would lose the MSB sign

[PATCH v8 15/18] irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP

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 Reviewed-by: Marc Zyngier --- v7 -> v8: - added Marc's R-b --- drivers/irqchip/irq-gic-v3-its.c | 1 +

[PATCH v8 13/18] genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation

Now we have a flag value indicating an IRQ domain implements MSI, let's set it on msi_create_irq_domain(). Signed-off-by: Eric Auger Reviewed-by: Marc Zyngier --- v7 -> v8 - Added Marc's R-b v6: new --- kernel/irq/msi.c | 4 ++-- 1 file changed,

[PATCH v8 12/18] irqdomain: Add irq domain MSI and MSI_REMAP flags

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 will be useful to check all MSI irq domains have MSI

[PATCH v8 18/18] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore

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 capability at MSI controller level, let's correct this. Signed-off-by: Eric

[PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap

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 preventing VFIO passthrough. As such any assigned

[PATCH v8 10/18] 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 those info in iommu-group sysfs. Signed-off-by: Eric Auger --- v3 -> v4: - do not handle PCI host bridge

[PATCH v8 09/18] iommu/amd: Declare MSI and HT regions as reserved IOVA regions

This patch registers the MSI and HT regions as non mappable reserved regions. They will be exposed in the iommu-group sysfs. For direct-mapped regions let's also use iommu_alloc_resv_region(). Signed-off-by: Eric Auger --- v6 -> v7: - use IOMMU_RESV_RESERVED v5:

[PATCH v8 11/18] iommu/arm-smmu-v3: Implement reserved region get/put callbacks

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 those info in iommu-group sysfs. Signed-off-by: Eric Auger

[PATCH v8 07/18] iommu: Implement reserved_regions iommu-group sysfs file

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 address, - third is the type. Signed-off-by: Eric Auger

[PATCH v8 08/18] iommu/vt-d: Implement reserved region get/put callbacks

This patch registers the [FEE0_h - FEF0_000h] 1MB MSI range as a reserved region and RMRR regions as direct regions. This will allow to report those reserved regions in the iommu-group sysfs. Signed-off-by: Eric Auger --- v6 -> v7: - report RMRR regions as direct

[PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Following LPC discussions, we now report reserved regions through the iommu-group sysfs reserved_regions attribute file. Reserved regions are populated through the IOMMU get_resv_region callback (former get_dm_regions), now implemented by amd-iommu, intel-iommu and arm-smmu: - the intel-iommu

[PATCH v8 05/18] iommu: Only map direct mapped regions

As we introduced new reserved region types which do not require mapping, let's make sure we only map direct mapped regions. Signed-off-by: Eric Auger --- v3 -> v4: - use region's type and reword commit message and title --- drivers/iommu/iommu.c | 3 +++ 1 file changed,

[PATCH v8 03/18] iommu: Add a new type field in iommu_resv_region

We introduce a new field to differentiate the reserved region types and specialize the apply_resv_region implementation. Legacy direct mapped regions have IOMMU_RESV_DIRECT type. We introduce 2 new reserved memory types: - IOMMU_RESV_MSI will characterize MSI regions that are mapped -

[PATCH v8 02/18] iommu: Rename iommu_dm_regions into iommu_resv_regions

We want to extend the callbacks used for dm regions and use them for reserved regions. Reserved regions can be - directly mapped regions - regions that cannot be iommu mapped (PCI host bridge windows, ...) - MSI regions (because they belong to another address space or because they are not

[PATCH v8 04/18] iommu: iommu_alloc_resv_region

Introduce a new helper serving the purpose to allocate a reserved region. This will be used in iommu driver implementing reserved region callbacks. Signed-off-by: Eric Auger --- v3 -> v4: - add INIT_LIST_HEAD(>list) - use int for prot param and add int type param -

[PATCH v8 06/18] iommu: iommu_get_group_resv_regions

Introduce iommu_get_group_resv_regions whose role consists in enumerating all devices from the group and collecting their reserved regions. The list is sorted and overlaps between regions of the same type are handled by merging the regions. Signed-off-by: Eric Auger ---

[PATCH v8 01/18] iommu/dma: Allow MSI-only cookies

From: Robin Murphy IOMMU domain users such as VFIO face a similar problem to DMA API ops with regard to mapping MSI messages in systems where the MSI write is subject to IOMMU translation. With the relevant infrastructure now in place for managed DMA domains, it's actually

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

On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote: > On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon wrote: > > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote: > >> Hmm, well we install the fault handler on the iommu_domain.. perhaps > >> maybe a combo of

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

Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point device ID to locate an IOMMU and check the reported max banks/counters. The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU, and uses it to acquire a reference to the first IOMMU, which does not work on certain

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

On January 11, 2017 4:03:50 AM GMT+01:00, Suravee Suthikulpanit wrote: > >Right Thanks for catching this. Do you want me to send out V8 with >this fix? Send only the corrected version of this patch please, as a reply to this message. Thanks. -- Sent from a