Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hi Tobias On 2016-07-18 18:43, Tobias Jakobi wrote: Marek Szyprowski wrote: On 2016-07-18 13:00, Tobias Jakobi wrote: Marek Szyprowski wrote: On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot

[PATCH v11 04/10] genirq/msi-doorbell: allow MSI doorbell (un)registration

This new API aims at allowing irqchips to allocate & register the MSI doorbells likely to be iommu mapped. Later on, other services will be added allowing the VFIO layer to query information based on all registered doorbells. Signed-off-by: Eric Auger --- v10 -> v11: -

[PATCH v11 02/10] 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 v11 01/10] 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 v11 07/10] irqchip/gicv2m: register the MSI global doorbell

Use the msi-doorbell API to register the global doorbell and implement the msi_doorbell_info Signed-off-by: Eric Auger --- v10 -> v11: - use the new registration API and re-implement the msi_doorbell_info ops v9 -> v10: - introduce the registration concept in place of

[PATCH v11 03/10] genirq/irq: introduce msi_doorbell_info

From: Eric Auger The purpose is to be able to retrieve the MSI doorbells of an irqchip. This is now needed since on some platforms those doorbells must be iommu mapped (in case the MSIs transit through an IOMMU that do not bypass those transactions). The assumption is

[PATCH v11 08/10] irqchip/gicv3-its: register the MSI global doorbell

This patch adds the registration of the MSI global doorbell in gicv3-its driver plus the implementation for irq_chip msi_doorbell_info ops. This will allow the msi layer to iommu_map this doorbell when requested. Signed-off-by: Eric Auger --- v10 -> v11: - adapt to new

[PATCH v11 06/10] 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 v11 00/10] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

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

[PATCH v11 05/10] 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 v11 09/10] 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 v11 10/10] 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 v11 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 the 2 previous parts (v11). 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

[PATCH v11 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

Re: [PATCH v11 03/10] genirq/irq: introduce msi_doorbell_info

On Tue, 19 Jul 2016, Eric Auger wrote: > > +/* Describe all the MSI doorbell regions for an irqchip */ > +struct irq_chip_msi_doorbell_info { > + union { > + phys_addr_t __percpu *percpu_doorbells; > + phys_addr_t global_doorbell; > + }; > + bool

Re: [PATCH v11 04/10] genirq/msi-doorbell: allow MSI doorbell (un)registration

On Tue, 19 Jul 2016, Eric Auger wrote: > + > +#include > +#include > +#include > + > +struct irqchip_doorbell { > + struct irq_chip_msi_doorbell_info info; > + struct list_head next; Again, please align the struct members. > +}; > + > +static LIST_HEAD(irqchip_doorbell_list); >

Re: [PATCH v11 05/10] genirq/msi-doorbell: msi_doorbell_pages

On Tue, 19 Jul 2016, Eric Auger wrote: > msi_doorbell_pages sum up the number of iommu pages of a given order adding () to the function name would make it immediately clear that msi_doorbell_pages is a function. > +/** > + * msi_doorbell_pages: compute the number of iommu pages of size 1 <<

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote: > On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote: > > On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote: > > > On Fri, Jun 17, 2016 at 08:26:52AM +0200, Marek Szyprowski wrote: > > > > From: "Rafael J.

[PATCH 3/3] vcodec: mediatek: Add probe-defer for MTK IOMMU and SMI

Mediatek V4l2 depend on the IOMMU and SMI. we should add probe-defer to wait for the IOMMU and SMI is ready. Signed-off-by: Yong Wu --- drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 1/3] memory: mediatek: Add a new interface mtk_smi_larb_is_ready

If it return false, the iommu consumer should probe-defer for the IOMMU and SMI. Signed-off-by: Yong Wu <yong...@mediatek.com> --- Adding this interface is for avoid adjust the sequence of power domain probe[1]. This patch-set is based on next-20160719. And patch[1/3] base on [2], pat

[PATCH 2/3] drm/mediatek: Add probe-defer for MTK IOMMU and SMI

If DRM begin to probe before SMI probe done. It will hang: [7.832359] Call trace: [7.834778] [] mtk_smi_larb_get+0x24/0xa8 [7.840300] [] mtk_drm_crtc_enable+0x6c/0x450 Use the new interface(mtk_smi_larb_is_ready) to wait for IOMMU and SMI probe done. Signed-off-by: Yong Wu

[PATCH v3 5/6] dmaengine: pl330: Make sure microcode is privileged

The PL330 performs privileged instruction fetches. This can result in SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which specifies that mappings that are writeable at one execution level shall not be executable at any higher-privileged level. Fix this by using the

[PATCH v3 0/6] Add support for privileged mappings

The following patch to the ARM SMMU driver: commit d346180e70b91b3d5a1ae7e5603e65593d4622bc Author: Robin Murphy Date: Tue Jan 26 18:06:34 2016 + iommu/arm-smmu: Treat all device transactions as unprivileged started forcing all SMMU

[PATCH v3 1/6] iommu: add IOMMU_PRIV attribute

Add the IOMMU_PRIV attribute, which is used to indicate privileged mappings. Signed-off-by: Mitchel Humpherys --- Notes: v2..v3 - Added comment include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h

[PATCH v3 4/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED

The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that are only accessible to privileged DMA engines. Implement it in dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. Signed-off-by: Mitchel Humpherys --- Notes: v2..v3

[PATCH v3 2/6] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

From: Jeremy Gebben Allow the creation of privileged mode mappings, for stage 1 only. Signed-off-by: Jeremy Gebben --- Notes: v2..v3 - Use existing bit definitions. drivers/iommu/io-pgtable-arm.c | 5 - 1 file changed, 4

[PATCH v3 3/6] common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute

This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping subsystem. Some advanced peripherals such as remote processors and GPUs perform accesses to DMA buffers in both privileged "supervisor" and unprivileged "user" modes. This attribute is used to indicate to the DMA-mapping

[PATCH v3 6/6] Revert "iommu/arm-smmu: Treat all device transactions as unprivileged"

This reverts commit d346180e70b9 ("iommu/arm-smmu: Treat all device transactions as unprivileged") since some platforms actually make use of privileged transactions. Signed-off-by: Mitchel Humpherys --- Notes: v2..v3 - Moved to the end of the series.