Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, 2017-10-19 at 12:58 -0400, Jerome Glisse wrote: > On Thu, Oct 19, 2017 at 09:53:11PM +1100, Balbir Singh wrote: > > On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse wrote: > > > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: > > > > On Mon, 16 Oct 2017

Re: [RFCv2 PATCH 01/36] iommu: Keep track of processes and PASIDs

few nits below. > +/* > + * Allocate a iommu_process structure for the given task. > + * > + * Ideally we shouldn't need the domain parameter, since iommu_process is > + * system-wide, but we use it to retrieve the driver's allocation ops and a > + * PASID range. > + */ > +static struct

Re: Shift overflow in qi_flush_dev_iotlb

On Fri, 20 Oct 2017 19:36:54 +0100 Tvrtko Ursulin wrote: > Hi all, > > Detected by ubsan: > > UBSAN: Undefined behaviour in drivers/iommu/dmar.c:1345:3 > shift exponent 64 is too large for 32-bit type 'int' > CPU: 2 PID: 1167 Comm: perf_pmu Not tainted 4.14.0-rc5+

Shift overflow in qi_flush_dev_iotlb

Hi all, Detected by ubsan: UBSAN: Undefined behaviour in drivers/iommu/dmar.c:1345:3 shift exponent 64 is too large for 32-bit type 'int' CPU: 2 PID: 1167 Comm: perf_pmu Not tainted 4.14.0-rc5+ #532 Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015 Call Trace:

Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Fri, Oct 20, 2017 at 11:27:41AM -0400, Jim Quinlan wrote: > memc0-a@[03fffefff] <=> pci@[03fffefff] > memc0-b@[1...13fffefff] <=> pci@[ 40007fffefff] > memc1-a@[ 40007fffefff] <=> pci@[ 8000bfffefff] >

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

Hi Joerg, Please pull these ARM SMMU updates for 4.15. The main improvement here is that we now drop the command queue lock when waiting for a CMD_SYNC to complete on implementations that support MSIs into cacheable memory. There are also some minor fixes and cleanups. Cheers, Will --->8 The

Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig wrote: > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote: >> I am not sure I understand your comment -- the size of the request >> shouldn't be a factor. Let's look at your example of the DMA request >> of 3f00 to

Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote: > I am not sure I understand your comment -- the size of the request > shouldn't be a factor. Let's look at your example of the DMA request > of 3f00 to 400f (physical memory). Lets say it is for 15 > pages. If we block out

Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Fri, Oct 20, 2017 at 3:37 AM, Christoph Hellwig wrote: > On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote: >> The only way to prevent this is to reserve a single page at the end of >> the first memory region of any pair that are adjacent in physical >> memory. A hack,

[PATCH] iommu: dmar: make include of x86_init.h conditional

The dmar driver can be used on both x86 and itanium, but only the former uses the x86_init structure. The only reference to that structure is enclosed in an #ifdef, but the header inclusion I added is not. Adds another #ifdef to get ia64 to build again. Fixes: 0f5a0f4f062c ("x86: don't include

Re: [PATCH v4 12/12] intel-ipu3: imgu top level pci device

On Tue, Oct 17, 2017 at 10:55:59PM -0500, Yong Zhi wrote: > This patch adds support for the Intel IPU v3 as found > on Skylake and Kaby Lake SoCs. The driver has a dependency > on the firmware binary to function properly. > > Signed-off-by: Yong Zhi > Signed-off-by: Tomasz

Re: [PATCH v2 0/8] MT2712 IOMMU SUPPORT

On Tue, 2017-08-22 at 22:38 +0800, Joerg Roedel wrote: > On Mon, Aug 21, 2017 at 07:00:13PM +0800, Yong Wu wrote: > > Yong Wu (8): > > dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI > > iommu/mediatek: Move MTK_M4U_TO_LARB/PORT into mtk_iommu.c > > iommu/mediatek: Add mt2712

RE: [PATCH v2 08/16] iommu: introduce device fault data

> -Original Message- > From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Wednesday, October 11, 2017 3:29 AM > To: Jacob Pan ; > iommu@lists.linux-foundation.org; > LKML ; Joerg Roedel

Re: [PATCH v4 02/12] intel-ipu3: Add mmu driver

Hi Yong, On Tue, Oct 17, 2017 at 10:48:34PM -0500, Yong Zhi wrote: > From: Tomasz Figa > > IPU3 is capable to deal with a virtual address space with > a dedicated MMU. The driver supports address translation > from virtual(IPU3 internal) to 39 bit wide physical(system). > >

Re: [PATCH v4 03/12] intel-ipu3: Add IOMMU based dmamap support

Hi Yong, On Tue, Oct 17, 2017 at 10:48:59PM -0500, Yong Zhi wrote: > From: Tomasz Figa > > This patch adds driver to support IPU3-specific > MMU-aware memory alloc/free and sg mapping functions. > > Signed-off-by: Tomasz Figa > Signed-off-by: Yong Zhi

Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset

Hi Yong, On Tue, Oct 17, 2017 at 10:46:48PM -0500, Yong Zhi wrote: > This patchset adds support for the Intel IPU3 (Image Processing Unit) > ImgU which is essentially a modern memory-to-memory ISP. It implements > raw Bayer to YUV image format conversion as well as a large number of > other pixel

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will, On 2017/10/20 16:36, Will Deacon wrote: > On Fri, Oct 20, 2017 at 03:00:01PM +0800, Yisheng Xie wrote: >> Any comment about this version? > > I have it queued up and plan to send a pull request to Joerg today for 4.15. Fine, thanks. Thanks Yisheng Xie > > Will > > . >

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

On Fri, Oct 20, 2017 at 03:00:01PM +0800, Yisheng Xie wrote: > Any comment about this version? I have it queued up and plan to send a pull request to Joerg today for 4.15. Will ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote: > The only way to prevent this is to reserve a single page at the end of > the first memory region of any pair that are adjacent in physical > memory. A hack, yes, but I don't see an easier way out of this. Many > if not most of our

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will & Jean, Any comment about this version? Thanks Yisheng Xie On 2017/9/21 20:36, Yisheng Xie wrote: > According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL > is not 0b00, which means we should not disable stall mode if stall > or terminate mode is not configuable. > >

RE: [PATCH 1/3] iommu/vt-d: Missing checks for pasid tables if allocation fails

> -Original Message- > From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Friday, October 20, 2017 8:49 AM > To: Liu, Yi L ; j...@8bytes.org; dw...@infradead.org > Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH 1/3]