Re: [GIT PULL] IOVA fix for 4.3

On Thu, 2015-10-01 at 16:42 -0400, Linus Torvalds wrote: > > Umm. What happened to this pull request? I want to see the expected > diffstat in addition to the shortlog... Ah crap, sorry. Here it is... Linus, please pull from git://git.infradead.org/intel-iommu.git Robin Murphy (1):

Re: [GIT PULL] IOVA fix for 4.3

On Wed, Sep 30, 2015 at 11:49 AM, David Woodhouse wrote: > > Linus, please pull from > > git://git.infradead.org/intel-iommu.git Umm. What happened to this pull request? I want to see the expected diffstat in addition to the shortlog... Linus ___

[PATCH v6 0/3] arm64: IOMMU-backed DMA mapping

Hi all, Here's the latest, and hopefully last, revision of the initial arm64 IOMMU dma_ops support. There are a couple of dependencies still currently in -next and the intel-iommu tree[0]: "iommu: iova: Move iova cache management to the iova library" is necessary for the rename of iova_cache_get(

[PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

Taking inspiration from the existing arch/arm code, break out some generic functions to interface the DMA-API to the IOMMU-API. This will do the bulk of the heavy lifting for IOMMU-backed dma-mapping. Since associating an IOVA allocator with an IOMMU domain is a fairly common need, rather than int

[PATCH v6 3/3] arm64: Hook up IOMMU dma_ops

With iommu_dma_ops in place, hook them up to the configuration code, so IOMMU-fronted devices will get them automatically. Acked-by: Catalin Marinas Signed-off-by: Robin Murphy --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 15 +++ arch/arm64

[PATCH v6 2/3] arm64: Add IOMMU dma_ops

Taking some inspiration from the arch/arm code, implement the arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer. Since there is still work to do elsewhere to make DMA configuration happen in a more appropriate order and properly support platform devices in the IOMMU core, the

Re: [PATCH] iommu/s390: add iommu api for s390 pci devices

On Tue, 29 Sep 2015 14:40:30 +0200 Joerg Roedel wrote: > Hi Gerald, > > thanks for your patch. It looks pretty good and addresses my previous > review comments. I have a few questions, first one is how this > operates with DMA-API on s390. Is there a seperate DMA-API > implementation besides the

Re: [PATCH 1/2] iommu/vt-d: Split iommu_prepare_identity_map

Hi Joerg, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: ia64-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/m

[PATCH 2/2] iommu/vt-d: Create RMRR mappings in newly allocated domains

From: Joerg Roedel Currently the RMRR entries are created only at boot time. This means they will vanish when the domain allocated at boot time is destroyed. This patch makes sure that also newly allocated domains will get RMRR mappings. Signed-off-by: Joerg Roedel --- drivers/iommu/intel-iomm

[PATCH 0/2] Fix remaining RMRR issues

Hi, here is a patch-set to fix a remaining RMRR issue in the VT-d driver. The problem was that RMRR mappings are only created for boot-time (or hotplug-time) allocated domains. Domains allocated on demand don't get RMRR mappings, which is bad for the kdump case, for example. With this patch-set t

[PATCH 1/2] iommu/vt-d: Split iommu_prepare_identity_map

From: Joerg Roedel Split the part of the function that fetches the domain out and put the rest into into a domain_prepare_identity_map, so that the code can also be used with when the domain is already known. Signed-off-by: Joerg Roedel --- drivers/iommu/intel-iommu.c | 40