From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH v5 1/3] iommu: Implement common IOMMU ops for DMA mapping Date: Tue, 11 Aug 2015 11:37:42 +0200 Message-ID: <20150811093742.GC14980@8bytes.org> References: <6ce6b501501f611297ae0eae31e07b0d2060eaae.1438362603.git.robin.murphy@arm.com> <20150807084228.GU14980@8bytes.org> <55C4B4DF.4040608@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55C4B4DF.4040608-5wv7dgnIgG8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Robin Murphy Cc: "laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org" , "arnd-r2nGTMty4D4@public.gmane.org" , Catalin Marinas , Will Deacon , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , "yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" , "treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" List-Id: iommu@lists.linux-foundation.org On Fri, Aug 07, 2015 at 02:38:39PM +0100, Robin Murphy wrote: > Indeed, DMA_DEBUG will check that a driver is making DMA API calls > to the arch code in the right way; this is a different check, to > catch things like the arch code passing the wrong domain into this > layer, or someone else having messed directly with the domain via > the IOMMU API. If the iommu_unmap doesn't match the IOVA region we > looked up, that means the IOMMU page tables have somehow become > inconsistent with the IOVA allocator, so we are in an unrecoverable > situation where we can no longer be sure what devices have access > to. That's bad. Sure, but the BUG_ON would also trigger on things like a double-free, which is bad to handle as a BUG_ON. A WARN_ON for this is sufficient. > AFAIK, yes (this is just a slight tidyup of the existing code that > 32-bit Exynos/Tegra/Rockchip/etc. devices are already using) - the > display guys want increasingly massive contiguous allocations for > framebuffers, layers, etc., so having IOMMU magic deal with that > saves CMA for non-IOMMU devices that really need it. Makes sense, I thougt about something similar for x86 too to avoid the high-order allocations we currently do. I guess the buffer will later be mapped into the vmalloc space for the CPU? Joerg