Re: [PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part)

2021-04-24 Thread Marc Zyngier
On Fri, 23 Apr 2021 18:58:23 +0100, Krishna Reddy wrote: > > >> Did that patch cause any issue, or is it just not needed on your system? > >> It fixes an hypothetical problem with the way ATS is implemented. > >> Maybe I actually observed it on an old software model, I don't > >> remember.

Re: [Patch V2 13/13] genirq/msi: Provide helpers to return Linux IRQ/dev_msi hw IRQ number

2021-03-26 Thread Marc Zyngier
On Fri, 26 Mar 2021 01:02:43 +, "Dey, Megha" wrote: > > Hi Marc, > > On 3/25/2021 10:53 AM, Marc Zyngier wrote: > > On Fri, 26 Feb 2021 20:11:17 +, > > Megha Dey wrote: > >> From: Dave Jiang > >> > >> Add new

Re: [Patch V2 08/13] genirq: Set auxiliary data for an interrupt

2021-03-26 Thread Marc Zyngier
On Thu, 25 Mar 2021 18:59:48 +, Thomas Gleixner wrote: > > On Thu, Mar 25 2021 at 17:23, Marc Zyngier wrote: > >> +{ > >> + struct irq_desc *desc; > >> + struct irq_data *data; > >> + unsigned long flags; > >> + int res = -ENODEV;

Re: [Patch V2 07/13] irqdomain/msi: Provide msi_alloc/free_store() callbacks

2021-03-26 Thread Marc Zyngier
On Thu, 25 Mar 2021 18:44:48 +, Thomas Gleixner wrote: > > On Thu, Mar 25 2021 at 17:08, Marc Zyngier wrote: > > Megha Dey wrote: > >> @@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain > >> *domain, struct device *dev, > >>

Re: [Patch V2 13/13] genirq/msi: Provide helpers to return Linux IRQ/dev_msi hw IRQ number

2021-03-25 Thread Marc Zyngier
On Fri, 26 Feb 2021 20:11:17 +, Megha Dey wrote: > > From: Dave Jiang > > Add new helpers to get the Linux IRQ number and device specific index > for given device-relative vector so that the drivers don't need to > allocate their own arrays to keep track of the vectors and hwirq for > the

Re: [Patch V2 12/13] irqchip: Add IMS (Interrupt Message Store) driver

2021-03-25 Thread Marc Zyngier
On Fri, 26 Feb 2021 20:11:16 +, Megha Dey wrote: > > Generic IMS(Interrupt Message Store) irq chips and irq domain > implementations for IMS based devices which store the interrupt messages > in an array in device memory. > > Allocation and freeing of interrupts happens via the generic >

Re: [Patch V2 08/13] genirq: Set auxiliary data for an interrupt

2021-03-25 Thread Marc Zyngier
On Fri, 26 Feb 2021 20:11:12 +, Megha Dey wrote: > > Introduce a new function pointer in the irq_chip structure(irq_set_auxdata) > which is responsible for updating data which is stored in a shared register > or data storage. For example, the idxd driver uses the auxiliary data API > to

Re: [Patch V2 07/13] irqdomain/msi: Provide msi_alloc/free_store() callbacks

2021-03-25 Thread Marc Zyngier
On Fri, 26 Feb 2021 20:11:11 +, Megha Dey wrote: > > From: Thomas Gleixner > > For devices which don't have a standard storage for MSI messages like the > upcoming IMS (Interrupt Message Store) it's required to allocate storage > space before allocating interrupts and after freeing them. >

Re: [RFC PATCH 3/5] KVM: ARM64: Add support for pinned VMIDs

2021-03-09 Thread Marc Zyngier
Hi Shameer, [+Will] On Mon, 22 Feb 2021 15:53:36 +, Shameer Kolothum wrote: > > On an ARM64 system with a SMMUv3 implementation that fully supports > Broadcast TLB Maintenance(BTM) feature, the CPU TLB invalidate > instructions are received by SMMU. This is very useful when the > SMMU

Re: iommu/vt-d: Cure VF irqdomain hickup

2020-11-13 Thread Marc Zyngier
On 2020-11-12 21:34, Thomas Gleixner wrote: On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote: The recent changes to store the MSI irqdomain pointer in struct device missed that Intel DMAR does not register virtual function devices. Due to that a VF device gets the plain PCI-MSI domain

Re: [PATCH v3 22/35] genirq/irqdomain: Implement get_name() method on irqchip fwnodes

2020-10-25 Thread Marc Zyngier
t_name = irqchip_fwnode_get_name, > +}; > EXPORT_SYMBOL_GPL(irqchip_fwnode_ops); > > /** Acked-by: Marc Zyngier -- Without deviation from the norm, progress is not possible. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

2020-08-28 Thread Marc Zyngier
On 2020-08-28 13:54, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote: > So the arch_setup_msi_irq/etc is not really an arch hook, but some > infrastructure to support those 4 PCI root port drivers. I happen to have a *really old* patch addressing Te

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

2020-08-28 Thread Marc Zyngier
Hi Jason, On 2020-08-28 13:19, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote: On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote: [...] > And I can't figure out what's special about tegra, rcar, and xilinx > that makes them need it as

Re: [patch V2 43/46] genirq/msi: Provide and use msi_domain_set_default_info_flags()

2020-08-27 Thread Marc Zyngier
On 2020-08-26 12:17, Thomas Gleixner wrote: MSI interrupts have some common flags which should be set not only for PCI/MSI interrupts. Move the PCI/MSI flag setting into a common function so it can be reused. Signed-off-by: Thomas Gleixner --- V2: New patch --- drivers/pci/msi.c |7

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

2020-08-26 Thread Marc Zyngier
On Wed, 26 Aug 2020 20:47:38 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:57 +0100, > > Thomas Gleixner wrote: > >> /** > >> - * msi_domain_free_irqs - Free interrupts from a MSI interr

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

2020-08-26 Thread Marc Zyngier
On Wed, 26 Aug 2020 22:19:56 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:32 +0100, > > Thomas Gleixner wrote: > >> --- > >> V2: New patch. Note, that this might break other stuff which reli

Re: [patch V2 41/46] platform-msi: Provide default irq_chip:: Ack

2020-08-26 Thread Marc Zyngier
= irq_chip_mask_parent; > if (!chip->irq_unmask) > chip->irq_unmask = irq_chip_unmask_parent; > + if (!chip->irq_ack) > + chip->irq_ack = irq_chip_ack_parent; > if (!chip->irq_eoi) > chip->irq_eoi = irq_chip_

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

2020-08-26 Thread Marc Zyngier
nel to support the Xilinx AXI PCIe @@ -105,7 +106,6 @@ config PCIE_XILINX_CPM bool "Xilinx Versal CPM host bridge support" depends on ARCH_ZYNQMP || COMPILE_TEST select PCI_HOST_COMMON - select PCI_MSI_ARCH_FALLBACKS help

Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI

2020-08-26 Thread Marc Zyngier
MSI domain. > + */ > + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI); > + One day, we'll be able to set the token at domain creation time. In the meantime, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possibl

Re: [patch V2 23/46] irqdomain/msi: Provide DOMAIN_BUS_VMD_MSI

2020-08-26 Thread Marc Zyngier
ch(domain->bus_token) { > + case DOMAIN_BUS_PCI_MSI: > + case DOMAIN_BUS_VMD_MSI: > + break; > + default: > return false; > + } > > if (!(info->flags & MSI_FLAG_MUST_REACTIVATE)) > return false; Acked-by: Mar

Re: [patch V2 17/46] PCI/MSI: Rework pci_msi_domain_calc_hwirq()

2020-08-26 Thread Marc Zyngier
On Wed, 26 Aug 2020 12:16:45 +0100, Thomas Gleixner wrote: > > From: Thomas Gleixner > > Retrieve the PCI device from the msi descriptor instead of doing so at the > call sites. > > Signed-off-by: Thomas Gleixner > Acked-by: Bjorn Helgaas Acked-by: Marc Zyngier

Re: [patch V2 19/46] x86/msi: Use generic MSI domain ops

2020-08-26 Thread Marc Zyngier
msi_prepare); > > -void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) > -{ > - arg->desc = desc; > - arg->hwirq = pci_msi_domain_calc_hwirq(desc); > -} > -EXPORT_SYMBOL_GPL(pci_msi_set_desc); I think that at this stage, pci_msi_domain_calc_hwirq() can

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

2020-08-26 Thread Marc Zyngier
/irq/chip.c +++ b/kernel/irq/chip.c @@ -1544,7 +1544,7 @@ int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) struct irq_data *pos = NULL; #ifdef CONFIG_IRQ_DOMAIN_HIERARCHY - for (; data; data = data->parent_data) + for (; data && !pos; data = data->paren

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

2020-08-26 Thread Marc Zyngier
truct irq_dom > } > > /** > + * __msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain > associated tp @dev Spurious __. > + * @domain: The domain to managing the interrupts > + * @dev: Pointer to device struct of the device for which the interrupts >

Re: [PATCH v3 0/3] Allow for qcom-pdc to be loadable as a module

2020-07-17 Thread Marc Zyngier
On Fri, 10 Jul 2020 23:18:21 +, John Stultz wrote: > This patch series provides exports and config tweaks to allow > the qcom-pdc driver to be able to be configured as a permement > modules (particularlly useful for the Android Generic Kernel > Image efforts). > > This was part of a larger

Re: [EXT] Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

2020-07-16 Thread Marc Zyngier
On 2020-07-16 04:23, Makarand Pawagi wrote: -Original Message- From: Lorenzo Pieralisi [...] Anyway - you need to seek feedback from Marc on whether patches 11 and 12 are OK from an irqchip perspective, it is possible we can take the rest of the series independently if everyone

Re: [PATCH v2 11/12] bus/fsl-mc: Refactor the MSI domain creation in the DPRC driver

2020-07-15 Thread Marc Zyngier
++-- drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 15 +- 5 files changed, 47 insertions(+), 40 deletions(-) For this patch and the following one: Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ iommu mailing

Re: [PATCH v2 3/5] irqchip: Allow QCOM_PDC to be loadable as a permanent module

2020-07-12 Thread Marc Zyngier
On Sat, 11 Jul 2020 00:27:45 +0100, Stephen Boyd wrote: > > Quoting John Stultz (2020-07-10 15:44:18) > > On Thu, Jul 9, 2020 at 11:02 PM Stephen Boyd wrote: > > > > > > Does it work? I haven't looked in detail but I worry that the child > > > irqdomain (i.e. pinctrl-msm) would need to delay

Re: [PATCH v2 3/5] irqchip: Allow QCOM_PDC to be loadable as a permanent module

2020-06-27 Thread Marc Zyngier
On Sat, 27 Jun 2020 02:34:25 +0100, John Stultz wrote: > > On Fri, Jun 26, 2020 at 12:42 AM Stephen Boyd wrote: > > > > Quoting John Stultz (2020-06-24 17:10:37) > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > > index 6ae9e1f0819d..3fee8b655da1 100644 > > > ---

Re: [RFC][PATCH 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-06-16 Thread Marc Zyngier
Hi John, +Will for the SMMU part. On 2020-06-16 07:13, John Stultz wrote: Allow the qcom_scm driver to be loadable as a permenent module. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linus Walleij Cc: Lina Iyer Cc

Re: [PATCH v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance

2020-05-21 Thread Marc Zyngier
On 2020-05-21 15:17, Will Deacon wrote: [+Marc] On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote: The SMMUv3 can handle invalidation targeted at TLB entries with shared ASIDs. If the implementation supports broadcast TLB maintenance, enable it and keep track of it in a

Re: arm-smmu-v3 high cpu usage for NVMe

2020-03-24 Thread Marc Zyngier
On Tue, 24 Mar 2020 09:18:10 + John Garry wrote: > On 23/03/2020 09:16, Marc Zyngier wrote: > > + Julien, Mark > > Hi Marc, > > >>> Time to enable pseudo-NMIs in the PMUv3 driver... > >>> > >> > >> Do you know if there is any p

Re: arm-smmu-v3 high cpu usage for NVMe

2020-03-23 Thread Marc Zyngier
On 2020-03-23 09:03, John Garry wrote: On 20/03/2020 16:33, Marc Zyngier wrote: JFYI, I've been playing for "perf annotate" today and it's giving strange results for my NVMe testing. So "report" looks somewhat sane, if not a worryingly high % for arm_smmu_cmdq_issue_cmdlist(

Re: arm-smmu-v3 high cpu usage for NVMe

2020-03-20 Thread Marc Zyngier
Hi John, On 2020-03-20 16:20, John Garry wrote: I've run a bunch of netperf instances on multiple cores and collecting SMMU usage (on TaiShan 2280). I'm getting the following ratio pretty consistently. - 6.07% arm_smmu_iotlb_sync - 5.74% arm_smmu_tlb_inv_range 5.09%

Re: [PATCH] iommu/rockchip: Don't provoke WARN for harmless IRQs

2019-11-12 Thread Marc Zyngier
return ret; if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks))) Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundat

Re: [PATCH] iommu/dma: Handle MSI mappings separately

2019-07-29 Thread Marc Zyngier
n business with a bnx2x device passed to a guest. FWIW: Tested-by: Marc Zyngier Thanks, M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 6/7] irqchip/gic-v3-mbi: Don't map the MSI page in mbi_compose_m{b, s}i_msg()

2019-05-03 Thread Marc Zyngier
On 01/05/2019 14:58, Julien Grall wrote: > The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible > context. However, on RT, iommu_dma_map_msi_msg() requires to be called > from a preemptible context. > > A recent patch split iommu_dma_map_msi_msg in two new functions: > one

Re: [PATCH v2 4/7] irqchip/gic-v3-its: Don't map the MSI page in its_irq_compose_msi_msg()

2019-05-01 Thread Marc Zyngier
On 01/05/2019 12:14, Julien Grall wrote: > On 30/04/2019 13:34, Auger Eric wrote: >> Hi Julien, > > Hi Eric, > > Thank you for the review! > >> >> On 4/29/19 4:44 PM, Julien Grall wrote: >>> its_irq_compose_msi_msg() may be called from non-preemptible context. >>> However, on RT,

Re: [PATCH v2 0/7] iommu/dma-iommu: Split iommu_dma_map_msi_msg in two parts

2019-04-29 Thread Marc Zyngier
Hi Julien, On 29/04/2019 15:44, Julien Grall wrote: > Hi all, > > On RT, the function iommu_dma_map_msi_msg expects to be called from > preemptible > context. However, this is not always the case resulting a splat with > !CONFIG_DEBUG_ATOMIC_SLEEP: > > [ 48.875777] BUG: sleeping function

Re: [PATCH v2 2/7] iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts

2019-04-29 Thread Marc Zyngier
On 29/04/2019 15:44, Julien Grall wrote: > On RT, iommu_dma_map_msi_msg() may be called from non-preemptible > context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as > the function is using spin_lock (they can sleep on RT). > > iommu_dma_map_msi_msg() is used to map the MSI page in

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

2019-04-23 Thread Marc Zyngier
On 23/04/2019 14:19, Robin Murphy wrote: > On 23/04/2019 12:46, Marc Zyngier wrote: >> On 23/04/2019 11:51, Julien Grall wrote: >>> On 4/23/19 11:23 AM, Marc Zyngier wrote: >>>> Hi Julien, >>> >>> Hi Marc, >>> >>>> On 18/04/

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

2019-04-23 Thread Marc Zyngier
On 23/04/2019 11:51, Julien Grall wrote: > On 4/23/19 11:23 AM, Marc Zyngier wrote: >> Hi Julien, > > Hi Marc, > >> On 18/04/2019 18:26, Julien Grall wrote: >>> When an MSI doorbell is located downstream of an IOMMU, it is required >>> to swizzle the phy

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

2019-04-23 Thread Marc Zyngier
Hi Julien, On 18/04/2019 18:26, Julien Grall wrote: > When an MSI doorbell is located downstream of an IOMMU, it is required > to swizzle the physical address with an appropriately-mapped IOVA for any > device attached to one of our DMA ops domain. > > At the moment, the allocation of the

Re: [PATCH v6 09/22] vfio: VFIO_IOMMU_BIND/UNBIND_MSI

2019-04-10 Thread Marc Zyngier
Hi Vincent, On 10/04/2019 13:35, Vincent Stehlé wrote: > On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote: >> Hi Marc, Robin, Alex, > (..) >> Do you think this is a reasonable assumption to consider devices within >> the same host iommu group share the same MSI doorbell? > > Hi Eric, >

Re: [PATCH] iommu: rockchip: Drop verbose prints in the interrupt handler

2018-09-27 Thread Marc Zyngier
On 26/09/18 18:31, Ezequiel Garcia wrote: On Tue, 2018-09-25 at 13:29 +0200, Joerg Roedel wrote: On Thu, Aug 30, 2018 at 07:28:32PM -0300, Ezequiel Garcia wrote: Printing verbosely via WARN macros and friends in interrupt handlers is strongly discouraged. Drop them and use proper ratelimited

Re: [PATCH] iommu/rockchip: Free irqs in shutdown handler

2018-09-20 Thread Marc Zyngier
ta(pdev); > + int i = 0, irq; > + > + while ((irq = platform_get_irq(pdev, i++)) != -ENXIO) > + devm_free_irq(iommu->dev, irq, iommu); > + > pm_runtime_force_suspend(>dev); > } > > -- > 2.17.0 > Acked-by: Marc Zyngier

Re: [PATCH] iommu/rockchip: Free irqs in shutdown handler

2018-09-11 Thread Marc Zyngier
mmu->dev, irq, iommu); + pm_runtime_force_suspend(>dev); } Looks OK to me. I don't think there is a point in using devm_irq* anymore in this driver, but that's a separate issue. Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___

[PATCH v2 4/4] iommu/rockchip: Move irq request past pm_runtime_enable

2018-08-24 Thread Marc Zyngier
in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 24 +--- 1 file c

[PATCH v2 2/4] arm64: rockchip: Force CONFIG_PM on Rockchip systems

2018-08-24 Thread Marc Zyngier
already does). Signed-off-by: Marc Zyngier --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index d5aeac351fc3..21a715ad8222 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms

[PATCH v2 0/4] iommu/rockchip: Runtime PM fixes

2018-08-24 Thread Marc Zyngier
/arm-kernel/msg670229.html * From v1: - Collected RBs from Heiko - Added two patches forcing CONFIG_PM on all Rockchip platforms at Heiko's request, following the example set by Tegra platforms. Marc Zyngier (4): ARM: rockchip: Force CONFIG_PM on Rockchip systems arm64: rockchip: Force

[PATCH v2 3/4] iommu/rockchip: Handle errors returned from PM framework

2018-08-24 Thread Marc Zyngier
let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-io

[PATCH v2 1/4] ARM: rockchip: Force CONFIG_PM on Rockchip systems

2018-08-24 Thread Marc Zyngier
already does). Signed-off-by: Marc Zyngier --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index fafd3d7f9f8c..8ca926522026 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip

Re: [PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

2018-08-07 Thread Marc Zyngier
On 07/08/18 14:15, Heiko Stuebner wrote: > Am Dienstag, 7. August 2018, 14:31:49 CEST schrieb Marc Zyngier: >> On 07/08/18 13:09, Heiko Stuebner wrote: >>> Hi Marc, >>> >>> Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier: >>>> pm_ru

Re: [PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

2018-08-07 Thread Marc Zyngier
On 07/08/18 13:09, Heiko Stuebner wrote: > Hi Marc, > > Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier: >> pm_runtime_get_if_in_use can fail: either PM has been disabled >> altogether (-EINVAL), or the device hasn't been enabled yet (0). >> Sadly, the

[PATCH 2/2] iommu/rockchip: Move irq request past pm_runtime_enable

2018-08-07 Thread Marc Zyngier
in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletion

[PATCH 0/2] iommu/rockchip: Runtime PM fixes

2018-08-07 Thread Marc Zyngier
). [1] https://www.spinics.net/lists/arm-kernel/msg670229.html Marc Zyngier (2): iommu/rockchip: Handle errors returned from PM framework iommu/rockchip: Move irq request past pm_runtime_enable drivers/iommu/rockchip-iommu.c | 45 +- 1 file changed, 28

[PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

2018-08-07 Thread Marc Zyngier
let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 21 +++-- 1 file c

Re: [PATCH] iommu/rockchip: Handle errors returned from PM framework

2018-08-06 Thread Marc Zyngier
Hi Heiko, On 06/08/18 13:09, Heiko Stuebner wrote: > Hi Marc, > > Am Sonntag, 5. August 2018, 14:46:16 CEST schrieb Marc Zyngier: >> pm_runtime_get_if_in_use can fail: either PM has been disabled >> altogether (-EINVAL), or the device hasn't been enabled yet (0). >>

[PATCH] iommu/rockchip: Handle errors returned from PM framework

2018-08-05 Thread Marc Zyngier
investigation, let's output a single warning (instead of flodding the console). In both cases, bail with an IRQ_NONE. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 7 --- 1 file changed, 4 insertions(+), 3

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

2018-06-13 Thread Marc Zyngier
On 13/06/18 10:20, Thomas Gleixner wrote: > On Wed, 13 Jun 2018, Julien Thierry wrote: >> On 13/06/18 09:34, Peter Zijlstra wrote: >>> On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote: diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index 5426627..dbc5e02

Re: [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed

2018-05-25 Thread Marc Zyngier
[Thanks Robin for pointing me to that patch.] Hi Heiko, On 24/05/18 23:06, Heiko Stübner wrote: > From: Sandy Huang > > The vop irq is shared between vop and iommu and irq probing in the > iommu driver moved to the probe function recently. This can in some > cases lead to

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

2018-04-12 Thread Marc Zyngier
On 12/04/18 11:17, Robin Murphy wrote: > On 11/04/18 17:54, Marc Zyngier wrote: >> Hi Sammer, >> >> On 11/04/18 16:58, Goel, Sameer wrote: >>> >>> >>> On 3/28/2018 9:00 AM, Marc Zyngier wrote: >>>> On 2018-03-28 15:39, Tim

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

2018-04-11 Thread Marc Zyngier
Hi Sammer, On 11/04/18 16:58, Goel, Sameer wrote: > > > On 3/28/2018 9:00 AM, Marc Zyngier wrote: >> On 2018-03-28 15:39, Timur Tabi wrote: >>> From: Sameer Goel <sg...@codeaurora.org> >>> >>> Set SMMU_GBPA to abort all incoming trans

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

2018-03-28 Thread Marc Zyngier
On 2018-03-28 15:39, Timur Tabi wrote: From: Sameer Goel Set SMMU_GBPA to abort all incoming translations during the SMMU reset when SMMUEN==0. This prevents a race condition where a stray DMA from the crashed primary kernel can try to access an IOVA address as an

[PATCH] iommu/rockchip: Perform a reset on shutdown

2018-02-20 Thread Marc Zyngier
our back. Note that we need to be extra cautious when doing so, as the IOMMU may not be clocked if controlled by a another master, as typical on Rockchip system. Suggested-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/iommu/rock

Re: [PATCH v2] iommu/arm-smmu-v3: limit reporting of MSI allocation failures

2018-01-22 Thread Marc Zyngier
i_msg); > if (ret) { > - dev_warn(dev, "failed to allocate MSIs\n"); > + dev_warn(dev, "failed to allocate MSIs - falling back to wired > irqs\n"); > return; > } > > Acked-by: Marc Zyngier &

Re: [PATCH] iommu/arm-smmu-v3: suppress MSI allocation failure message

2018-01-17 Thread Marc Zyngier
On 17/01/18 18:54, Robin Murphy wrote: > [ +Marc just in case ] > > On 17/01/18 18:39, Nate Watterson wrote: >> From: Sinan Kaya >> >> Even though QDF2400 supports MSI interrupts with SMMUv3, it is not enabled >> in ACPI FW to preserve compatibility with older kernel

Re: [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

2017-12-15 Thread Marc Zyngier
/irqchip/irq-gic-v3-its.c | 3 +- > include/linux/acpi_iort.h| 7 ++- > 3 files changed, 116 insertions(+), 5 deletions(-) For the ITS part: Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> M. ___ iommu mailing list

Re: [PATCH v8 2/5] ACPI/IORT: Add msi address regions reservation helper

2017-10-04 Thread Marc Zyngier
On 27/09/17 14:32, Shameer Kolothum wrote: > On some platforms msi parent address regions have to be excluded from > normal IOVA allocation in that they are detected and decoded in a HW > specific way by system components and so they cannot be considered normal > IOVA address space. > > Add a

Re: [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper

2017-10-04 Thread Marc Zyngier
On 27/09/17 14:32, Shameer Kolothum wrote: > From: John Garry > > On some platforms msi-controller address regions have to be excluded > from normal IOVA allocation in that they are detected and decoded in > a HW specific way by system components and so they cannot be

Re: [PATCH] iommu: Avoid NULL group dereference

2017-08-17 Thread Marc Zyngier
ng rather familiar, but now it's backed by the reasoning of having > a robust API able to do the expected thing for all devices regardless. > > Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory") > Reported-by: Shawn Lin <shawn@rock-chips.c

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

2017-08-17 Thread Marc Zyngier
On 17/08/17 10:01, Shawn Lin wrote: > Hi Marc > > On 2017/8/17 16:52, Marc Zyngier wrote: >> On 17/08/17 09:28, Shawn Lin wrote: >>> If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't >>> have iommu support, we don't need to do iommu_dma_map_msi_ms

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

2017-08-17 Thread Marc Zyngier
On 17/08/17 09:28, Shawn Lin wrote: > If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't > have iommu support, we don't need to do iommu_dma_map_msi_msg to > get mapped iommu address as all we need is the physical address. > Otherwise we see the oops shown below as we can't get a

Re: PCIe oops for NULL pointer dereference during next-20170807 and next-20170815

2017-08-17 Thread Marc Zyngier
On 17/08/17 08:58, Joerg Roedel wrote: > On Thu, Aug 17, 2017 at 03:02:31PM +0800, Shawn Lin wrote: >> So should we revert this commit or maybe we could add some checking >> into gic-v2m and gic-v3-its to see if the dev is iommu-capable? If not, >> we should create another routine to map MSI msg.

Re: [PATCH v8 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

2017-06-21 Thread Marc Zyngier
On 21/06/17 10:08, Will Deacon wrote: > Hi Geetha, > > On Wed, Jun 21, 2017 at 12:09:45PM +0530, Geetha Akula wrote: >> On Tue, Jun 20, 2017 at 11:30 PM, Will Deacon wrote: >>> On Tue, Jun 20, 2017 at 07:47:39PM +0530, Geetha sowjanya wrote: From: Geetha Sowjanya

Re: Device address specific mapping of arm,mmu-500

2017-05-30 Thread Marc Zyngier
On 30/05/17 18:16, Ray Jui wrote: > Hi Marc, > > On 5/30/17 9:59 AM, Marc Zyngier wrote: >> On 30/05/17 17:49, Ray Jui wrote: >>> Hi Will, >>> >>> On 5/30/17 8:14 AM, Will Deacon wrote: >>>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray

Re: Device address specific mapping of arm,mmu-500

2017-05-30 Thread Marc Zyngier
On 30/05/17 17:49, Ray Jui wrote: > Hi Will, > > On 5/30/17 8:14 AM, Will Deacon wrote: >> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: >>> I'm writing to check with you to see if the latest arm-smmu.c driver in >>> v4.12-rc Linux for smmu-500 can support mapping that is only specific

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

2017-01-10 Thread Marc Zyngier
info->data = its; > inner_domain->host_data = info; > For patches 13 to 16, and provided that you address the couple of nits I mentioned in reply to patches 13 and 15: Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> Thanks, M. -- Jazz is not dead. It just s

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

2017-01-10 Thread Marc Zyngier
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

2017-01-10 Thread Marc Zyngier
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

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

2017-01-06 Thread Marc Zyngier
On 06/01/17 04:27, Bharat Bhushan wrote: > Hi Mark, > >> -Original Message- >> From: Auger Eric [mailto:eric.au...@redhat.com] >> Sent: Thursday, January 05, 2017 5:39 PM >> To: Marc Zyngier <marc.zyng...@arm.com>; eric.auger@gmail.com; >&

Re: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level

2017-01-06 Thread Marc Zyngier
On 06/01/17 09:08, Auger Eric wrote: > Hi Bharat > > On 06/01/2017 09:50, Bharat Bhushan wrote: >> Hi Eric, >> >>> -Original Message- >>> From: Eric Auger [mailto:eric.au...@redhat.com] >>> Sent: Friday, January 06, 2017 12:35 AM >>> To: eric.au...@redhat.com; eric.auger@gmail.com;

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

2017-01-05 Thread Marc Zyngier
On 05/01/17 11:29, Auger Eric wrote: > Hi Marc, > > On 05/01/2017 12:25, Marc Zyngier wrote: >> On 05/01/17 10:45, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 16:27, Marc Zyngier wrote: >>>> On 04/01/17 14:11, Auger Eric wrote: >&g

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

2017-01-05 Thread Marc Zyngier
On 05/01/17 10:45, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 16:27, Marc Zyngier wrote: >> On 04/01/17 14:11, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 14:46, Marc Zyngier wrote: >>>> Hi Eric, >>>> >>>&g

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

2017-01-04 Thread Marc Zyngier
On 04/01/17 14:11, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 14:46, Marc Zyngier wrote: >> Hi Eric, >> >> On 04/01/17 13:32, Eric Auger wrote: >>> This new function checks whether all platform and PCI >>> MSI domains implement IRQ remapping.

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

2017-01-04 Thread Marc Zyngier
Hi Eric, On 04/01/17 13:32, Eric Auger wrote: > This new function checks whether all platform and PCI > MSI 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 >

Re: [PATCH v3] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

2016-12-20 Thread Marc Zyngier
Geetha, On 20/12/16 11:06, Geetha sowjanya wrote: > From: Tirumalesh Chalamarla > > This patch implements Cavium ThunderX erratum 28168. > > PCI requires stores complete in order. Due to erratum #28168 > PCI-inbound MSI-X store to the interrupt controller

Re: [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

2016-11-16 Thread Marc Zyngier
On 15/11/16 18:24, David Daney wrote: > On 11/15/2016 01:26 AM, Marc Zyngier wrote: >> On 15/11/16 07:00, Geetha sowjanya wrote: >>> From: Tirumalesh Chalamarla <tirumalesh.chalama...@cavium.com> >>> >>>This patch implements Cavium ThunderX err

Re: [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

2016-11-15 Thread Marc Zyngier
On 15/11/16 07:00, Geetha sowjanya wrote: > From: Tirumalesh Chalamarla > > This patch implements Cavium ThunderX erratum 28168. > > PCI requires stores complete in order. Due to erratum #28168 > PCI-inbound MSI-X store to the interrupt controller are

Re: [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

2016-10-24 Thread Marc Zyngier
Geetha, On 22/10/16 05:54, Geetha sowjanya wrote: > From: Tirumalesh Chalamarla > > This patch implements Cavium ThunderX erratum 28168. > > PCI requires stores complete in order. Due to erratum #28168 > PCI-inbound MSI-X store to the interrupt

Re: [PATCH v6.1] iommu/dma: Add support for mapping MSIs

2016-09-09 Thread Marc Zyngier
vice attached to one of our DMA > ops domains. > > CC: Thomas Gleixner <t...@linutronix.de> > CC: Jason Cooper <ja...@lakedaemon.net> > CC: Marc Zyngier <marc.zyng...@arm.com> > CC: linux-ker...@vger.kernel.org > Signed-off-by: Robin Murphy <robin.mur...@arm.

Re: [PATCH v2 3/7] of/irq: Break out msi-map lookup (again)

2016-06-04 Thread Marc Zyngier
property. Drag the > core parsing routine up yet another layer into the general OF-PCI code, > and further generalise it for either kind of lookup in either flavour > of map property. > > CC: Rob Herring <robh...@kernel.org> > CC: Frank Rowand <frowand.l...@gmail.com> >

Re: [PATCH v8 7/8] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

2016-05-04 Thread Marc Zyngier
On 28/04/16 09:22, Eric Auger wrote: > 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.

Re: [PATCH v8 6/8] irqchip/gicv2m: implement msi_doorbell_info callback

2016-05-04 Thread Marc Zyngier
On 28/04/16 09:22, Eric Auger wrote: > This patch implements the msi_doorbell_info callback in the > gicv2m driver. > > The driver now is able to return its doorbell characteristics > (base, size, prot). A single doorbell is exposed. > > This will allow the msi layer to iommu_map this doorbell

Re: [PATCH v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback

2016-04-20 Thread Marc Zyngier
On Wed, 20 Apr 2016 14:33:17 +0200 Eric Auger <eric.au...@linaro.org> wrote: > Marc, > On 04/20/2016 11:27 AM, Marc Zyngier wrote: > > On 19/04/16 18:13, Eric Auger wrote: > >> This patch implements the msi_doorbell_info callback in the > >> gicv2m driv

Re: [PATCH v7 8/8] genirq/msi: use the MSI doorbell's IOVA when requested

2016-04-20 Thread Marc Zyngier
On 19/04/16 18:13, Eric Auger wrote: > 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

Re: [PATCH v7 09/10] iommu/dma-reserved-iommu: iommu_msi_mapping_translate_msg

2016-04-20 Thread Marc Zyngier
On 19/04/16 17:56, Eric Auger wrote: > Introduce iommu_msi_mapping_translate_msg 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

Re: [PATCH v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback

2016-04-20 Thread Marc Zyngier
On 19/04/16 18:13, Eric Auger wrote: > This patch implements the msi_doorbell_info callback in the > gicv2m driver. > > The driver now is able to return its doorbell characteristics > (base, size, prot). A single doorbell is exposed. > > This will allow the msi layer to iommu_map this doorbell

Re: [PATCH v7 5/8] genirq/irq: introduce msi_doorbell's structs and related callback

2016-04-20 Thread Marc Zyngier
On 19/04/16 18:13, Eric Auger wrote: > 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

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

2016-02-18 Thread Marc Zyngier
On Fri, 12 Feb 2016 08:13:17 + Eric Auger wrote: > 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

  1   2   >