Re: [PATCH v2 06/11] iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus

Hi Magnus, Thank you for the patch. I agree with the comment that Geert made on v1, and I haven't seen you replying to it or addressing it. Quoting Geert, "I think this should be handled in drivers/iommu/of_iommu.c:of_iommu_init() instead, cfr. commit 3e5dd6f6e690048d ("clk: Ignore disabled

Re: [PATCH 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

Hi Magnus, Thank you for the patch. On Tuesday 07 Jun 2016 12:39:45 Magnus Damm wrote: > From: Magnus Damm > > Support the r8a7796 IPMMU by sharing feature flags between > r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook > up the updated compat string. > >

Re: [PATCH 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding

Hi Magnus, Thank you for the patch. On Tuesday 07 Jun 2016 12:39:27 Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU DT binding documentation to include the r8a7796 compat > string for R-Car M3-W. > > Signed-off-by: Magnus Damm

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

Hi Magnus, Thank you for the patch. On Tuesday 07 Jun 2016 12:39:36 Magnus Damm wrote: > From: Magnus Damm > > Bump up the maximum numbers of micro-TLBS to 48. > > Each IPMMU device instance get micro-TLB assignment via > the "iommus" property in DT. Older SoCs

Re: [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

Hi Magnus, On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm wrote: > iommu/ipmmu-vmsa: IPMMU multi-arch update V3 > > [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling > [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for > context >

Re: [PATCH v10 4/8] vfio/type1: handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots

Hello, Le 07/06/2016 à 18:44, kbuild test robot a écrit : > Hi, > > [auto build test ERROR on vfio/next] > [also build test ERROR on v4.7-rc2 next-20160607] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url:

Re: [PATCH v10 4/8] vfio/type1: handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots

Hi, [auto build test ERROR on vfio/next] [also build test ERROR on v4.7-rc2 next-20160607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64-kernel

[PATCH v10 6/8] vfio/type1: check doorbell safety

On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted by the msi controller. Since we currently have no way to detect whether the MSI controller is upstream or downstream to the IOMMU we rely on the MSI doorbell information registered by the interrupt controllers. In case at

[PATCH v10 8/8] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

This patch allows the user-space to retrieve the MSI geometry. The implementation is based on capability chains, now also added to VFIO_IOMMU_GET_INFO. The returned info comprise: - whether the MSI IOVA are constrained to a reserved range (x86 case) and in the positive, the start/end of the

[PATCH v10 7/8] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP

Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu(-v3). 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 remapping capability, the msi domain needs to be checked instead. This commit affects platform

[PATCH v10 5/8] vfio: allow reserved msi iova registration

The user is allowed to register a reserved MSI IOVA range by using the DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. This region is stored in the vfio_dma rb tree. At that point the iova range is not mapped to any target address yet. The host kernel will use those iova

[PATCH v10 4/8] vfio/type1: handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots

Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots, let's implement the expected behavior for removal and replay. As opposed to user dma slots, reserved IOVAs are not systematically bound to PAs and PAs are not pinned. VFIO just initializes the IOVA "aperture". IOVAs are

[PATCH v10 3/8] vfio/type1: implement recursive vfio_find_dma_from_node

This patch handles the case where a node is encountered, matching @start and @size arguments but not matching the @type argument. In that case, we need to skip that node and pursue the search in the node's leaves. In case @start is inferior to the node's base, we resume the search on the left

[PATCH v10 2/8] vfio/type1: vfio_find_dma accepting a type argument

In our RB-tree we get prepared to insert slots of different types (USER and RESERVED). It becomes useful to be able to search for dma slots of a specific type or any type. This patch introduces vfio_find_dma_from_node which starts the search from a given node and stops on the first node that

[PATCH v10 1/8] vfio: introduce a vfio_dma type field

We introduce a vfio_dma type since we will need to discriminate different types of dma slots: - VFIO_IOVA_USER: IOVA region used to map user vaddr - VFIO_IOVA_RESERVED_MSI: IOVA region reserved to map MSI doorbells Signed-off-by: Eric Auger --- v9 -> v10: - renamed

[PATCH v10 9/9] genirq/msi: use the MSI doorbell's IOVA when requested

On MSI message composition we now use the MSI doorbell's IOVA in place of the doorbell's PA in case the device is upstream to an IOMMU that requires MSI addresses to be mapped. The doorbell's allocation and mapping happened on an early stage (pci_enable_msi). Signed-off-by: Eric Auger

[PATCH v10 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes

This series allows the user-space to register a reserved IOVA domain. This completes the kernel integration of the whole functionality on top of part1 (v10) & part2 (v9). We reuse the VFIO DMA MAP ioctl with a new flag to bridge to the msi-iommu API. The need for provisioning such MSI IOVA range

[PATCH v10 8/9] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

This patch handles the iommu mapping of MSI doorbells that require to be mapped in an iommu domain. This happens on msi_domain_alloc/free_irqs since this is called in code that can sleep (pci_enable/disable_msi): iommu_map/unmap is not stated as atomic. On msi_domain_(de)activate and

[PATCH v10 7/9] irqchip/gicv3-its: register the MSI global doorbell

This patch adds the registration of the MSI global doorbell in gicv3-its driver. This will allow the msi layer to iommu_map this doorbell when requested. Signed-off-by: Eric Auger --- drivers/irqchip/irq-gic-v3-its.c | 14 ++ 1 file changed, 14 insertions(+)

[PATCH v10 6/9] irqchip/gicv2m: register the MSI global doorbell

Use the msi-doorbell API to register the global doorbell. Signed-off-by: Eric Auger --- v9 -> v10: - introduce the registration concept in place of msi_doorbell_info callback v8 -> v9: - use global_doorbell instead of percpu_doorbells v7 -> v8: -

[PATCH v10 4/9] genirq/msi-doorbell: msi_doorbell_pages

msi_doorbell_pages sum up the number of iommu pages of a given order requested to map all the registered doorbells. This function will allow to dimension the intermediate physical address (IPA) aperture requested to map the MSI doorbells. Signed-off-by: Eric Auger ---

[PATCH v10 3/9] genirq/msi-doorbell: creation

This new API aims at managing MSI doorbells likely to be iommu mapped. The API is bound to be used at least by irqchip drivers, the MSI layer and the VFIO sub-system. Irqchips likely to be downstream to IOMMUs (that do not bypass MSI transactions) need to register their MSI doorbells so that the

[PATCH v10 5/9] genirq/msi-doorbell: msi_doorbell_safe

msi_doorbell_safe returns whether all the registered doorbells implement irq_remapping. When assigning a PCIe device whose host controller is upstream to an IOMMU, we currently do not know whether the MSI controller is upstream or downstream to the IOMMU. Signed-off-by: Eric Auger

[PATCH v10 2/9] genirq/msi: msi_compose wrapper

Currently the MSI message is composed by directly calling irq_chip_compose_msi_msg and erased by setting the memory to zero. On some platforms, we will need to complexify this composition to properly handle MSI emission through IOMMU. Also we will need to track when the MSI message is erased. We

[PATCH v10 1/9] genirq/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 --- v2 -> v3: - remove static implementation in case CONFIG_PCI_MSI_IRQ_DOMAIN is not set --- kernel/irq/msi.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v10 0/9] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

This series implements the MSI address mapping/unmapping in the MSI layer. IOMMU binding happens on pci_enable_msi since this function can sleep and return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which are not allowed to sleep, we simply look for the already existing binding.

[PATCH v10 5/8] iommu/msi-iommu: iommu_msi_[get,put]_doorbell_iova

iommu_msi_get_doorbell_iova allows to iommu map an MSI doorbell contiguous physical region onto a reserved contiguous IOVA region. The physical region base address does not need to be iommu page size aligned. iova pages are allocated and mapped so that they cover all the physical region. This

[PATCH v10 7/8] iommu/msi-iommu: iommu_msi_msg_pa_to_va

Introduce iommu_msi_msg_pa_to_va whose role consists in detecting whether the device's MSIs must to be mapped into an IOMMU. It case it must, the function overrides the MSI msg originally composed and replaces the doorbell's PA by a pre-allocated and pre-mapped reserved IOVA. In case the

[PATCH v10 8/8] iommu/arm-smmu: get/put the msi cookie

For IOMMU_DOMAIN_UNMANAGED type we now also get the msi cookie in both arm-smmu and arm-smmu-v3. This initializes resources for MSI doorbell mapping. Signed-off-by: Eric Auger --- drivers/iommu/arm-smmu-v3.c | 16 drivers/iommu/arm-smmu.c| 15

[PATCH v10 3/8] iommu: introduce an msi cookie

This opaque pointer will enable to store information about msi iommu mappings. Signed-off-by: Eric Auger --- v7 -> v8: remove spinlock and RB tree v5 -> v6: - initialize reserved_binding_list - use a spinlock instead of a mutex --- include/linux/iommu.h | 1 + 1 file

[PATCH v10 6/8] iommu/msi-iommu: iommu_msi_domain

This function checks whether - the device belongs to a non default iommu domain - this iommu domain requires the MSI address to be mapped. If those conditions are met, the function returns the iommu domain to be used for mapping the MSI doorbell; else it returns NULL. Signed-off-by: Eric Auger

[PATCH v10 1/8] iommu: Add iommu_domain_msi_geometry and DOMAIN_ATTR_MSI_GEOMETRY

Introduce a new DOMAIN_ATTR_MSI_GEOMETRY domain attribute. It enables to query the aperture of the IOVA window dedicated to MSIs and test whether the MSIs must be mapped with the IOMMU-MSI API. x86 IOMMUs will typically expose an MSI aperture matching the 1MB region [FEE0_h - FEF0_000h]

[PATCH v10 2/8] iommu/arm-smmu: initialize the msi geometry and advertise iommu-msi support

On ARM, MSI write transactions from device upstream to the smmu are conveyed through the iommu. Therefore target physical addresses must be mapped and DOMAIN_ATTR_MSI_GEOMETRY advertises the support of the IOMMU-MSI API. Signed-off-by: Eric Auger --- v8 -> v9: - reword

[PATCH v10 4/8] iommu/msi-iommu: initialization

iommu_get/put_msi_cookie allocates/frees the resource used to store and ref count the MSI doorbell mappings. iommu_msi_set_aperture initializes the iova domain used for MSI IOVA allocation and sets the iommu domain's msi geometry. The implementation relies on dma-iommu API and iova API. New msi

[PATCH v10 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

This series introduces the msi-iommu api used to: - allocate/free resources for MSI IOMMU mapping - set the MSI iova window aperture - map/unmap physical addresses onto MSI IOVAs. - determine whether an msi needs to be iommu mapped - overwrite an msi_msg PA address with its pre-allocated/mapped

[RFC PATCH v2 13/15] drivers: acpi: iort: introduce iort_iommu_configure

DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the

[RFC PATCH v2 15/15] drivers: iommu: arm-smmu-v3: allow ACPI based streamid translation

The ACPI IORT table provides data to ARM SMMU drivers to carry out streamid mappings and the kernel has the infrastructure to implement it through the iommu_xlate() IORT SMMU operation hook. By reusing the infrastructure implemented for of_xlate(), this patch adds the ARM SMMU v3 iommu_xlate()

[RFC PATCH v2 14/15] drivers: acpi: iort: add function to retrieve IOMMU platform devices

Some kernel components (ie ARM SMMU drivers) require to look-up the platform device corresponding to a specific IORT node to carry out streamid translation. Platform devices created for ARM SMMU components out of IORT tables have no fwnode token initialized, in that they do not have any device

[RFC PATCH v2 05/15] drivers: acpi: iort: add support for named component look-up

ACPI IORT table allows ids translations for PCI devices (through their respective root complex) and name components (ie components identified through their ACPI namespace path). Current IORT code only allows look-up and retrieval of IORT nodes corresponding to PCI root complexes components; this

[RFC PATCH v2 04/15] drivers: acpi: iort: add support for IOMMU registration

The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective IOMMU

[RFC PATCH v2 08/15] drivers: acpi: iort: add support for ARM SMMU platform devices creation

In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

[RFC PATCH v2 12/15] drivers: acpi: implement acpi_dma_configure

On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

[RFC PATCH v2 03/15] arm64: mm: change IOMMU notifier action to attach DMA ops

Current bus notifier in ARM64 (__iommu_attach_notifier) attempts to attach dma_ops to a device on BUS_NOTIFY_ADD_DEVICE action notification. This causes issues on ACPI based systems, where PCI devices can be added before the IOMMUs the devices are attached to had a chance to be probed, causing

[RFC PATCH v2 10/15] drivers: iommu: arm-smmu-v3: enable ACPI driver initialization

On systems booting with ACPI that enable the ARM SMMU components in the kernel config options, the ARM SMMU v3 init function (ie arm_smmu_init(), that registers the driver and sets-up bus iommu operations) does not run only because the device tree interface (of_find_matching_node()) fails to find

[RFC PATCH v2 11/15] drivers: iommu: arm-smmu-v3: add IORT iommu configuration

In ACPI bases systems, in order to be able to create platform devices and initialize them for arm-smmu-v3 components, the IORT infrastructure requires ARM SMMU drivers to initialize a set of operations that are used by the IORT kernel layer to configure platform devices for ARM SMMU components in

[RFC PATCH v2 09/15] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[RFC PATCH v2 07/15] drivers: acpi: iort: add node match function

Device drivers (eg ARM SMMU) need to know if a specific component is part of the IORT table, so that kernel data structures are not initialized at initcalls time if the respective component is not part of the IORT table. To this end, this patch adds a trivial function that allows detecting if a

[RFC PATCH v2 06/15] drivers: acpi: iort: enhance device identifiers mappings

Current IORT code only allow to map device identifiers to the corresponding ITS group device id. This is not sufficient, in that current code does not allow device id mappings to components that sit between devices and ITS interrupt controllers (eg IOMMUs). This patch enhances the current IORT

[RFC PATCH v2 02/15] drivers: irqchip: its: fix its_acpi_probe() prototype

The empty stub for its_acpi_probe() on !CONFIG_ACPI systems has a wrong prototype, which causes compilation errors: drivers/irqchip/irq-gic-v3-its.c: In function 'its_init': drivers/irqchip/irq-gic-v3-its.c:1762:3: error: too few arguments to function 'its_acpi_probe' its_acpi_probe(); ^

[RFC PATCH v2 00/15] ACPI IORT ARM SMMU v3 support

This RFC patch series is v2 of a previous posting: https://lkml.org/lkml/2016/4/14/702 v1 -> v2: - Rebased on top of dependencies series [1][2][3](v4.7-rc1) - Removed IOMMU fwnode generalization - Implemented ARM SMMU v3 ACPI probing instead of ARM SMMU v2 owing

[RFC PATCH v2 01/15] drivers: acpi: iort: fix struct pci_dev compiler warnings

When the kernel is configured with no IORT support the compilation issues the following warnings: In file included from drivers/irqchip/irq-gic-v3-its-pci-msi.c:19:0: include/linux/iort.h:28:33: warning: 'struct pci_dev' declared inside parameter list u32 iort_pci_get_msi_rid(struct pci_dev

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

Hello. On 6/7/2016 6:39 AM, Magnus Damm wrote: From: Magnus Damm Bump up the maximum numbers of micro-TLBS to 48. Each IPMMU device instance get micro-TLB assignment via the "iommus" property in DT. Older SoCs tend to use a maximum number of 32 micro-TLBd per

Re: [RFC v3 20/45] xen: dma-mapping: Use unsigned long for dma_attrs

On 02/06/16 16:39, Krzysztof Kozlowski wrote: > Split out subsystem specific changes for easier reviews. This will be > squashed with main commit. Acked-by: David Vrabel David ___ iommu mailing list

[PATCHv8 4/6] arm: dma-mapping: add {map, unmap}_resource for iommu ops

Add methods to map/unmap device resources addresses for dma_map_ops that are IOMMU aware. This is needed to map a device MMIO register from a physical address. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCHv8 2/6] dma-debug: add support for resource mappings

A MMIO mapped resource can not be represented by a struct page so a new debug type is needed to handle this. This patch add such type and functionality to add/remove entries and how to translate them to a physical address. Signed-off-by: Niklas Söderlund

[PATCHv8 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers

Enable slave transfers to a device behind a IPMMU by mapping the slave addresses using the dma-mapping API. Signed-off-by: Niklas Söderlund --- drivers/dma/sh/rcar-dmac.c | 82 +- 1 file changed, 74

[PATCHv8 5/6] dmaengine: rcar-dmac: group slave configuration

Group slave address and transfer size in own structs for source and destination. This is in preparation for hooking up the dma-mapping API to the slave addresses. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCHv8 1/6] dma-mapping: add {map,unmap}_resource to dma_map_ops

Add methods to handle mapping of device resources from a physical address. This is needed for example to be able to map MMIO FIFO registers to a IOMMU. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart ---

[PATCHv8 3/6] dma-mapping: add dma_{map,unmap}_resource

Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops method is available the operation is a no-op. Signed-off-by: Niklas Söderlund --- Documentation/DMA-API.txt | 22 +- include/linux/dma-mapping.h | 36

[PATCHv8 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

Hi, This series tries to solve the problem with DMA with device registers (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A recent patch '9575632 (dmaengine: make slave address physical)' clarifies that DMA slave address provided by clients is the physical address. This puts

Re: [PATCH 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support

Hi Magnus, On Tue, Jun 7, 2016 at 5:39 AM, Magnus Damm wrote: > iommu/ipmmu-vmsa: Initial r8a7796 support > > [PATCH 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding > [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 > [PATCH 3/3] iommu/ipmmu-vmsa: Hook up