[PATCH v2 2/2] Documentation/kernel-parameters.txt : Remove IA-64 from iommu=pt doc

Remove IA-64 from iommu=pt doc There is no sign of either iommu parameter parsing or use of iommu_pass_through in arch/ia64/kernel/pci-dma.c, so remove IA-64 from iommu=pt documentation. This patch depends on patch iommu_default_pt.patch. Signed-off-by: Glenn Serre ---

[PATCH v2 1/2] arch/x86: Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt

Add CONFIG_IOMMU_DEFAULT_PT for iommu=pt Allow default to iommu=pt without adding to command line. Add iommu=nopt to turn off default. The reason we use iommu=pt is to support using the DPDK igb_uio driver, which we need to do on servers that have an iommu but lack ACS. Signed-off-by: Glenn

Re: [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s

On Mon, Oct 17, 2016 at 03:19:46PM +0100, Robin Murphy wrote: > Hi Lorenzo, > > On 17/10/16 14:21, Lorenzo Pieralisi wrote: > > On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote: > >> We now delay installing our per-bus iommu_ops until we know an SMMU has > >> successfully probed, as

[PATCH] iommu: fix double spin_lock_irqsave on `device_domain_lock'

From: Iago Abal The EBA code analyzer (https://github.com/models-team/eba) reported the following double lock: 1. In function `disable_dmar_iommu' defined at 1706; 2. the lock `device_domain_lock' is first taken in line 1714: // FIRST

Re: [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64

Auger Eric writes: > Hi Punit, > > On 14/10/2016 13:24, Punit Agrawal wrote: >> Hi Eric, >> >> I am a bit late in joining, but I've tried to familiarise >> myself with earlier discussions on the series. >> >> Eric Auger writes: >> >>> This is the

Re: [PATCH v14 04/16] iommu/dma: MSI doorbell alloc/free

Hi Punit, On 14/10/2016 13:25, Punit Agrawal wrote: > Hi Eric, > > One query and a comment below. > > Eric Auger writes: > >> We introduce the capability to (un)register MSI doorbells. >> >> A doorbell region is characterized by its physical address base, size, >> and

Re: [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64

Hi Punit, On 14/10/2016 13:24, Punit Agrawal wrote: > Hi Eric, > > I am a bit late in joining, but I've tried to familiarise > myself with earlier discussions on the series. > > Eric Auger writes: > >> This is the second respin on top of Robin's series [1], addressing

Re: [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s

Hi Lorenzo, On 17/10/16 14:21, Lorenzo Pieralisi wrote: > On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote: >> We now delay installing our per-bus iommu_ops until we know an SMMU has >> successfully probed, as they don't serve much purpose beforehand, and >> doing so also avoids

RE: [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s

Hi, >-Original Message- >From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org] >On Behalf Of Robin Murphy >Sent: Monday, October 17, 2016 4:36 PM >To: will.dea...@arm.com; j...@8bytes.org >Cc: iommu@lists.linux-foundation.org; Lorenzo Pieralisi

Re: [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s

On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote: > We now delay installing our per-bus iommu_ops until we know an SMMU has > successfully probed, as they don't serve much purpose beforehand, and > doing so also avoids fights between multiple IOMMU drivers in a single > kernel.

[PATCH 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()

With no coherency to worry about, just plug'em straight in. CC: Catalin Marinas CC: Will Deacon Signed-off-by: Robin Murphy --- arch/arm64/mm/dma-mapping.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 1/2] iommu/dma: Implement dma_{map,unmap}_resource()

With the new dma_{map,unmap}_resource() functions added to the DMA API for the benefit of cases like slave DMA, add suitable implementations to the arsenal of our generic layer. Since cache maintenance should not be a concern, these can both be standalone versions without the need for

[PATCH] iommu/iova: Extend cached node lookup condition

When searching for a free IOVA range, we optimise the tree traversal by starting from the cached32_node, instead of the last node, when limit_pfn is equal to dma_32bit_pfn. However, if limit_pfn happens to be smaller, then we'll go ahead and start from the top even though dma_32bit_pfn is still a

[PATCH 2/2] iommu/mediatek: Convert M4Uv1 to iommu_fwspec

Our per-device data consists of the M4U instance and firmware-provided list of LARB IDs, which is a perfect fit for the generic iommu_fwspec machinery. Use that directly instead of the custom archdata code - while we can't rely on the of_xlate() mechanism to initialise things until the 32-bit ARM

[PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec

Our per-device data consists of the M4U instance and firmware-provided list of LARB IDs, which is a perfect fit for the generic iommu_fwspec machinery. Use that directly as a simpler alternative to the custom archdata code. CC: Yong Wu Signed-off-by: Robin Murphy

[PATCH 1/2] iommu: Favour per-instance IOMMU ops

On systems with multiple IOMMUs, bus-level granularity can be too coarse, particularly on the platform "bus", where the hardware may actually warrant multiple different iommu_ops, which we currently have no way at all to accommodate. As an initial step towards the necessary flexibility, allow the

[PATCH 2/2] iommu/arm-smmu: Work around ARM DMA configuration

The 32-bit ARM DMA configuration code predates the IOMMU core's default domain functionality, and instead relies on allocating its own domains and attaching any devices using the generic IOMMU binding to them. Unfortunately, it does this relatively early on in the creation of the device, before

[PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s

We now delay installing our per-bus iommu_ops until we know an SMMU has successfully probed, as they don't serve much purpose beforehand, and doing so also avoids fights between multiple IOMMU drivers in a single kernel. However, the upshot of passing the return value of bus_set_iommu() back from

RE: [PATCH V3 0/8] IOMMU probe deferral support

Resending, missed out on the link last time. >-Original Message- >From: linux-arm-msm-ow...@vger.kernel.org >[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Marek Szyprowski >Sent: Monday, October 10, 2016 6:07 PM >To: Sricharan R ;

RE: [PATCH V3 0/8] IOMMU probe deferral support

>-Original Message- >From: Sricharan [mailto:sricha...@codeaurora.org] >Sent: Wednesday, October 12, 2016 11:55 AM >To: 'Marek Szyprowski' ; 'will.dea...@arm.com' >; 'robin.mur...@arm.com' >; 'j...@8bytes.org'