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

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

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

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

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

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

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)

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

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 v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback

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

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

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

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

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

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

Re: [RFC v3 07/15] iommu: iommu_get/put_single_reserved

On Fri, 12 Feb 2016 08:13:09 + Eric Auger wrote: > 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

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

; __u32 flags; > #define VFIO_IOMMU_INFO_PGSIZES (1 << 0) /* supported page sizes info */ > +#define VFIO_IOMMU_INFO_REQUIRE_MSI_MAP (1 << 1)/* MSI must be mapped */ > __u64 iova_pgsizes; /* Bitmap of supported page sizes */ > }; > FWIW: Acked-by: Marc Zyngier <marc.zyng...@arm.com> 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] iommu/arm-smmu: Add support for MSI on SMMUv3

On 13/10/15 16:41, Will Deacon wrote: > Hi Marc, > > On Thu, Oct 08, 2015 at 03:52:00PM +0100, Marc Zyngier wrote: >> Despite being a platform device, the SMMUv3 is capable of signaling >> interrupts using MSIs. Hook it into the platform MSI framework and >> enjoy fau

[PATCH v3] iommu/arm-smmu: Add support for MSI on SMMUv3

Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- * From v2: - MSI indexes as an enum -

[PATCH] iommu/arm-smmu: Add support for MSI on SMMUv3

Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/iommu/arm-smmu-v3.

[PATCH v2] iommu/arm-smmu: Add support for MSI on SMMUv3

Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- Now rebased on top of Will's iommu/devel

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

v4.3. Marc, can I take it from your use of the binding that you are happy to provide your ack? Definitely. Acked-by: Marc Zyngier marc.zyng...@arm.com M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

On 27/07/15 10:46, Mark Rutland wrote: On Mon, Jul 27, 2015 at 09:02:46AM +0100, Marc Zyngier wrote: Hi Mark, Hi, On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used in a couple of drivers despite being fairly underspecified. This patch adds a generic binding for MSIs

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

Hi Mark, On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used in a couple of drivers despite being fairly underspecified. This patch adds a generic binding for MSIs (including the existing msi-parent property) enabling the description of platform devices capable of using MSIs.

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used by a few bindings to describe the relationship between a PCI root complex and a single MSI controller, but this property does not have a generic binding document. Additionally, msi-parent is insufficient to describe more

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

On Thu, 23 Jul 2015 19:26:11 +0100 David Daney dda...@caviumnetworks.com wrote: On 07/23/2015 09:52 AM, Mark Rutland wrote: [...] +MSI clients +=== + +MSI clients are devices which generate MSIs. For each MSI they wish to +generate, the doorbell and payload may be configured,

Re: [PATCH v13 00/18] VFIO support for platform devices

Hi Baptiste, On 26/02/15 17:02, Baptiste Reynal wrote: Hi everyone, Are there any comments on this patch series? If not, Is there anything keeping this series from getting merged upstream? For a start, it looks like the dependency mentioned below is still not in, which is a bit of a

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Fri, Jun 27 2014 at 10:57:28 PM, Chalamarla, Tirumalesh tirumalesh.chalama...@caviumnetworks.com wrote: Marc, What is your opinion on ITS emulation . is it should be part of KVM or VFIO. Making any sort of emulation part of VFIO sounds quite wrong. That's not what VFIO

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

On 01/05/14 15:36, Dave Martin wrote: On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote: On Thursday 01 May 2014 12:15:35 Dave Martin wrote: On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote: On Tuesday 29 April 2014 19:16:02 Dave Martin wrote: [...] For example,

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

On 01/05/14 16:53, Arnd Bergmann wrote: On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote: On 01/05/14 15:36, Dave Martin wrote: On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote: On Thursday 01 May 2014 12:15:35 Dave Martin wrote: On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd

Re: [PATCH 0/2] ARM SMMU fixes

On 08/04/14 14:41, Laurent Pinchart wrote: I've obviously forgotten that Will was away for a month. CC'ing Marc Zyngier. On Thursday 03 April 2014 01:52:55 Laurent Pinchart wrote: On Friday 28 February 2014 16:37:08 Laurent Pinchart wrote: Hello Will, I've studied your arm-smmu driver

<    1   2