Re: [GIT PULL] iommu/arm-smmu: Updates for 4.14

On Fri, Aug 18, 2017 at 04:19:48PM +0100, Will Deacon wrote: > The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e: > > Linux 4.13-rc4 (2017-08-06 18:44:49 -0700) > > are available in the git repository at: > >

[PATCH 2/2] iommu/amd: Fix section mismatch warning

From: Joerg Roedel The variable amd_iommu_pre_enabled is used in non-init code-paths, so remove the __initdata annotation. Fixes: 3ac3e5ee5ed56 ('iommu/amd: Copy old trans table from old kernel') Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu_init.c

[PATCH 1/2] iommu/amd: Fix compiler warning in copy_device_table()

From: Joerg Roedel This was reported by the kbuild bot. The condition in which entry would be used uninitialized can not happen, because when there is no iommu this function would never be called. But its no fast-path, so fix the warning anyway. Reported-by: kbuild test robot

[PATCH 2/3] iommu/arm-smmu-v3: Forget about cmdq-sync interrupt

The cmdq-sync interrupt is never going to be particularly useful, since for stage 1 DMA at least we'll often need to wait for sync completion within someone else's IRQ handler, thus have to implement polling anyway. Beyond that, the overhead of taking an interrupt, then still having to grovel

[PATCH 0/3] SMMUv3 CMD_SYNC optimisation

Hi all, Waiting for the command queue to drain for CMD_SYNC completion is likely a contention hotspot on high-core-count systems. If the SMMU is coherent and supports MSIs, though, we can use this cool feature (as suggested by the architecture, no less) to make syncs effectively non-blocking for

[PATCH 1/3] iommu/arm-smmu-v3: Specialise CMD_SYNC handling

CMD_SYNC already has a bit of special treatment here and there, but as we're about to extend it with more functionality for completing outside the CMDQ lock, things are going to get rather messy if we keep trying to cram everything into a single generic command interface. Instead, let's break out

Re: [PATCH v2 4/4] iommu: Prevent VMD child devices from being remapping targets

On 18/08/17 17:04, Bjorn Helgaas wrote: > [+cc Robin] > > This series looks fine to me as far as PCI is concerned, and I'd be > happy to take it via my tree given an ack from David for this IOMMU > piece. Alternatively, you can add my > > Acked-by: Bjorn Helgaas > > to

Re: [PATCH v2 4/4] iommu: Prevent VMD child devices from being remapping targets

[+cc Robin] This series looks fine to me as far as PCI is concerned, and I'd be happy to take it via my tree given an ack from David for this IOMMU piece. Alternatively, you can add my Acked-by: Bjorn Helgaas to the other patches if you want to take it via another tree.

[GIT PULL] iommu/arm-smmu: Updates for 4.14

Hi Joerg, It's been a quiet cycle on the SMMU front, but please pull these three patches for 4.14. They're all in relation to power management and device shutdown, which allows us to handle suspend/resume and kexec operations gracefully. Cheers, Will --->8 The following changes since commit

Re: [PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

Hi Joerg, On Thu, Aug 17, 2017 at 11:20:54PM +0200, Joerg Roedel wrote: > On Thu, Aug 17, 2017 at 06:17:05PM +0100, Will Deacon wrote: > > On Thu, Aug 17, 2017 at 06:50:40PM +0200, Joerg Roedel wrote: > > > Problem currently is how to get this information from > > > 'struct iommu_device' to

[iommu:x86/amd 6/12] WARNING: vmlinux.o(.text+0x600c17): Section mismatch in reference from the function early_enable_iommus() to the variable .init.data:amd_iommu_pre_enabled

tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git x86/amd head: 20b46dff13bd1d250dc968b318f0fac3c996b3fa commit: 3ac3e5ee5ed56b07448f295902e44916eb6979fc [6/12] iommu/amd: Copy old trans table from old kernel config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian

[iommu:x86/amd 6/12] drivers//iommu/amd_iommu_init.c:887:17: warning: 'entry' may be used uninitialized in this function

tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git x86/amd head: 20b46dff13bd1d250dc968b318f0fac3c996b3fa commit: 3ac3e5ee5ed56b07448f295902e44916eb6979fc [6/12] iommu/amd: Copy old trans table from old kernel config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian

Re: [PATCH 2/2] iommu/tegra-gart: Add support for struct iommu_device

On Thu, Aug 10, 2017 at 12:29:12AM +0200, Joerg Roedel wrote: > From: Joerg Roedel > > Add a struct iommu_device to each tegra-gart and register it > with the iommu-core. Also link devices added to the driver > to their respective hardware iommus. > > Signed-off-by: Joerg

Re: [PATCH 1/2] iommu/tegra: Add support for struct iommu_device

On Thu, Aug 10, 2017 at 12:29:11AM +0200, Joerg Roedel wrote: > From: Joerg Roedel > > Add a struct iommu_device to each tegra-smmu and register it > with the iommu-core. Also link devices added to the driver > to their respective hardware iommus. > > Signed-off-by: Joerg

Re: [PATCH] iommu: Avoid NULL group dereference

On Thu, Aug 17, 2017 at 05:56:23PM +0100, Robin Murphy wrote: > On 17/08/17 16:41, Joerg Roedel wrote: > > Okay, so just to check I got it right: Drivers do the above to check > > whether a device is managed by an IOMMU, and that crashes now because > > the 'group == NULL' check was removed? > >

Re: [PATCH 0/4] Patches to support ring0 SVM and devtlb

Hi Ashok, On Tue, Aug 15, 2017 at 07:59:29AM -0700, Raj, Ashok wrote: > I haven't received any update to this patchset.. > > Could you help get this merged through your tree? we have tested this > series internally. The mm-notifier patch needs acks or rb from mm-developers before I can merge

Re: [PATCH 0/5] arm-smmu: performance optimization

On Fri, Aug 18, 2017 at 11:19:00AM +0800, Leizhen (ThunderTown) wrote: > > > On 2017/8/17 22:36, Will Deacon wrote: > > Thunder, Nate, Robin, > > > > On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote: > >> I described the optimization more detail in patch 1 and 2, and patch 3-5 > >> are

Re: [RFC v2 2/4] iommu/arm-smmu-v3: Add tlbi_on_map option

Hi Michael, On 18/08/2017 04:54, Michael S. Tsirkin wrote: > On Thu, Aug 17, 2017 at 07:47:04PM +0200, Auger Eric wrote: >> I will see with Peter and other potential users in the community whether >> it is worth to pursue the efforts on upstreaming the QEMU vSMMUv3 >> device, considering the