Re: [PATCH V3 5/5] perf/amd/iommu: Enable support for multiple IOMMUs

Hi Boris, Thank you very much for catching several styling issues. I should have taken care of that earlier. I'll clean them up. Please see my other comments below. Thanks, Suravee On 02/11/2016 12:14 AM, Borislav Petkov wrote: On Tue, Feb 09, 2016 at 04:53:55PM -0600, Suravee

[PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs

The current amd_iommu_pc_get_set_reg_val() does not support muli-IOMMU system. This patch replace amd_iommu_pc_get_set_reg_val() with amd_iommu_pc_set_reg_val() and amd_iommu_pc_[set|get]_cnt_vals(). Also, the current struct hw_perf_event.prev_count can only store the previous counter value only

[PATCH V4 6/6] perf/amd/iommu: Clean up print messages pr_debug

From: Suravee Suthikulpanit This patch declares pr_fmt for perf/amd_iommu, removes unnecessary pr_debug, and clean up error messages. Signed-off-by: Suravee Suthikulpanit --- arch/x86/events/amd/iommu.c | 13 + 1 file

[PATCH V4 2/6] perf/amd/iommu: Modify functions to query max banks and counters

Currently, amd_iommu_pc_get_max_[banks|counters]() require devid, which should not be the case. Also, these don't properly support multi-IOMMU system. Current and future AMD systems with IOMMU that support perf counter would likely contain homogeneous IOMMUs where multiple IOMMUs are availalbe.

[PATCH V4 4/6] perf/amd/iommu: Introduce get_iommu_bnk_cnt_evt_idx

Introduce a helper function to calculate bit-index for assigning performance counter assignment. Signed-off-by: Suravee Suthikulpanit --- arch/x86/events/amd/iommu.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git

[PATCH V4 3/6] iommu/amd: Introduce amd_iommu_get_num_iommus()

This patch introduces amd_iommu_get_num_iommus(). Initially, this is intended to be used by Perf AMD IOMMU driver. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/perf/amd/iommu.h | 2 ++ drivers/iommu/amd_iommu_init.c| 7 ++- 2 files

[PATCH V4 1/6] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

From: Suravee Suthikulpanit First, this patch move arch/x86/events/amd/iommu.h to arch/x86/include/asm/perf/amd/iommu.h so that we easily include it in both perf-amd-iommu and amd-iommu drivers. Then, we consolidate declarion of AMD IOMMU performance counter APIs

[PATCH V4 0/6] perf/amd/iommu: Enable multi-IOMMU support

From: Suravee Suthikulpanit This patch series modifies the existing perf_event_amd_iommu driver to support systems with multiple IOMMUs. It introduces new AMD IOMMU APIs, which are used by the AMD IOMMU Perf driver to access performance counters in multiple IOMMUs.

[RFC v2 10/15] vfio: allow the user to register reserved iova range for MSI mapping

The user is allowed to register a reserved IOVA range by using the DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. It provides the base address and the size. This region is stored in the vfio_dma rb tree. At that point the iova range is not mapped to any target address

[RFC v2 12/15] msi: export msi_get_domain_info

We plan to use msi_get_domain_info in VFIO module so let's export it. Signed-off-by: Eric Auger --- include/linux/msi.h | 4 kernel/irq/msi.c| 1 + 2 files changed, 5 insertions(+) diff --git a/include/linux/msi.h b/include/linux/msi.h index 03eda72..df19315

[RFC v2 00/15] KVM PCIe/MSI passthrough on ARM/ARM64

This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64. It pursues the efforts done on [1], [2], [3]. It also aims at covering the same need on PowerPC platforms although the same kind of integration should be carried out. On x86 all accesses to the 1MB PA region [FEE0_h -

[RFC v2 05/15] iommu/arm-smmu: implement alloc/free_reserved_iova_domain

Implement alloc/free_reserved_iova_domain for arm-smmu. we use the iova allocator (iova.c). The iova_domain is attached to the arm_smmu_domain struct. A mutex is introduced to protect it. Signed-off-by: Eric Auger --- v1 -> v2: - formerly implemented in vfio_iommu_type1

[RFC v2 03/15] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type

We introduce a vfio_dma type since we will need to discriminate legacy vfio_dma's from new reserved ones. Since those latter are not mapped at registration, some treatments need to be reworked: removal, replay. Currently they are unplugged. In subsequent patches they will be reworked.

[RFC v2 06/15] iommu/arm-smmu: add a reserved binding RB tree

we will need to track which host physical addresses are mapped to reserved IOVA. In that prospect we introduce a new RB tree indexed by physical address. This RB tree only is used for reserved IOVA bindings. It is expected this RB tree will contain very few bindings. Those generally correspond to

[RFC v2 04/15] iommu: add alloc/free_reserved_iova_domain

Introduce alloc/free_reserved_iova_domain in the IOMMU API. alloc_reserved_iova_domain initializes an iova domain at a given iova base address and with a given size. This iova domain will be used to allocate iova within that window. Those IOVAs will be reserved for special purpose, typically MSI

[RFC v2 01/15] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute

Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported, this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS and FSL PAMU, at least expose this attribute. x86 IOMMUs typically don't expose the attribute since on x86, MSI write transaction addresses always are

[RFC v2 07/15] iommu: iommu_get/put_single_reserved

This patch introduces iommu_get/put_single_reserved. iommu_get_single_reserved allows to allocate a new reserved iova page and map it onto the physical page that contains a given physical address. It returns the iova that is mapped onto the provided physical address. Hence the physical address

[RFC v2 02/15] vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO

This patch allows the user-space to retrieve whether msi write transaction addresses must be mapped. This is returned through the VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP. Signed-off-by: Bharat Bhushan Signed-off-by: Eric Auger

[RFC v2 11/15] msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING meant to tell the domain supports IRQ REMAPPING, also known as Interrupt Translation Service. On Intel HW this capability is abstracted on IOMMU side while on ARM it is abstracted on MSI controller side. GICv3 ITS HW is the

[RFC v2 09/15] iommu/arm-smmu: relinquish reserved resources on domain deletion

arm_smmu_unmap_reserved releases all reserved binding resources: destroy all bindings, free iova, free iova_domain. This happens on domain deletion. Signed-off-by: Eric Auger --- drivers/iommu/arm-smmu.c | 34 +- 1 file changed, 29

[RFC v2 13/15] vfio/type1: also check IRQ remapping capability at msi domain

On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted by the msi controller. vfio_msi_parent_irq_remapping_capable allows to check whether interrupts are "safe" for a given device. There are if the device does not use MSI or if the device uses MSI and the msi-parent controller

[RFC v2 08/15] iommu/arm-smmu: implement iommu_get/put_single_reserved

Implement the iommu_get/put_single_reserved API in arm-smmu. In order to track which physical address is already mapped we use the RB tree indexed by PA. Signed-off-by: Eric Auger --- v1 -> v2: - previously in vfio_iommu_type1.c --- drivers/iommu/arm-smmu.c | 114

[RFC v2 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame when needed

In case the msi_desc references a device attached to an iommu domain, the msi address needs to be mapped in the IOMMU. Else any MSI write transaction will cause a fault. gic_set_msi_addr detects that case and allocates an iova bound to the physical address page comprising the MSI frame. This iova

[RFC v2 14/15] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP

Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu. Indeed the irq_remapping capability is abstracted on irqchip side for ARM as opposed to Intel IOMMU featuring IRQ remapping HW. So to check IRQ remmapping capability, the msi domain needs to be checked instead. Signed-off-by: Eric Auger

Re: [PATCH v3 1/8] iommu: Add MMIO mapping type

On 11/02/16 00:02, Laurent Pinchart wrote: Hi Niklas, Thank you for the patch. On Wednesday 10 February 2016 01:57:51 Niklas Söderlund wrote: From: Robin Murphy On some platforms, MMIO regions might need slightly different treatment compared to mapping regular memory;

[PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling

As the number of io-pgtable implementations grows beyond 1, it's time to rationalise the quirks mechanism before things have a chance to start getting really ugly and out-of-hand. To that end: - Indicate exactly which quirks each format can/does support. - Fail creating a table if a caller wants

Re: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling

Hi Robin, Thank you for the patch. On Thursday 11 February 2016 16:13:45 Robin Murphy wrote: > As the number of io-pgtable implementations grows beyond 1, it's time > to rationalise the quirks mechanism before things have a chance to > start getting really ugly and out-of-hand. > > To that end: