From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753140AbcKHOxg (ORCPT ); Tue, 8 Nov 2016 09:53:36 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:17001 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751359AbcKHOxa (ORCPT ); Tue, 8 Nov 2016 09:53:30 -0500 X-AuditID: cbfec7f5-f79ce6d000004c54-8f-5821e6e5f986 Subject: Re: [PATCH] iommu/dma-iommu: properly respect configured address space size To: Robin Murphy , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Joerg Roedel From: Marek Szyprowski Message-id: <6f2f3d37-dc6c-abdb-9692-8dcc9cad36f3@samsung.com> Date: Tue, 08 Nov 2016 15:53:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42LZduznOd2nzxQjDPZOkbdYsN/aonP2BnaL TY+vsVpc3jWHzeLghyesDqweTw7OY/JYM28No8fmJfUek28sZ/T4vEkugDWKyyYlNSezLLVI 3y6BK2PXjXfsBeukK471bGZtYJwo1sXIwSEhYCLRdECji5ETyBSTuHBvPVsXIxeHkMBSRonu G/OYIJzPjBJ/rxxkhqgykWg4dBMqsYxR4mjfXbCEkMBzRolTO8pAbGGBMImF/StYQIpEBPoZ JbqmtDKBJJgFlCSOrj3DAmKzCRhKdL3tYgOxeQXsJBbeWcgIYrMIqEoc/9EHNlRUIEbi9pRr zBA1ghI/Jt8D6+UUsJZo/P2IHWKmlcSzf62sELa8xOY1b5lBFksI9LNL7OhvZIb4U1Zi0wGo D1wkji24yAphC0u8Or6FHcKWkejsOMgEYQMd3dSqDWHPYJQ495YXwraWOHz8ItQuPolJ26ZD jeeV6GgTgjA9JH7+SYaodpQ4s/YFCySsNjFJHDz7kW0Co/wsJN/MQvLBLCQfLGBkXsUoklpa nJueWmyqV5yYW1yal66XnJ+7iRGYNE7/O/51B+PSY1aHGAU4GJV4eDMeKkYIsSaWFVfmHmKU 4GBWEuH1eQIU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzrtnwZVwIYH0xJLU7NTUgtQimCwTB6dU A6Pww+VrxO1D3m0+9DlZVlpTzGRrXkPU0jm3FVcbBr2KcUlYOaf7RVRwpN71YweSuRqL/317 xPwlIk2Bs4W1dY2NkThnMkf36b+2RUp1n19GSups2VoWfNrr8yGDJMnZHk/NTmou3hZfffXY q7zvPgZnvmusSlmvlRWaPufKfrUqOz2lXesmNymxFGckGmoxFxUnAgCH22ZlFgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsVy+t/xy7pPnilGGEzaz2axYL+1RefsDewW mx5fY7W4vGsOm8XBD09YHVg9nhycx+SxZt4aRo/NS+o9Jt9YzujxeZNcAGuUm01GamJKapFC al5yfkpmXrqtUmiIm66FkkJeYm6qrVKErm9IkJJCWWJOKZBnZIAGHJwD3IOV9O0S3DJ23XjH XrBOuuJYz2bWBsaJYl2MnBwSAiYSDYduMkHYYhIX7q1n62Lk4hASWMIoca1tOzOE85xRYsOS WUAZDg5hgTCJGYdsQOIiAv2MEuvu/mGBKNrCJPG76QAbyChmASWJo2vPsIDYbAKGEl1vu8Di vAJ2EgvvLGQEsVkEVCWO/+hjBrFFBWIkrj97BFUjKPFj8j2wXk4Ba4nG34/YIWaaSXx5eZgV wpaX2LzmLfMERoFZSFpmISmbhaRsASPzKkaR1NLi3PTcYkO94sTc4tK8dL3k/NxNjMA42nbs 5+YdjJc2Bh9iFOBgVOLhzXioGCHEmlhWXJl7iFGCg1lJhNfnCVCINyWxsiq1KD++qDQntfgQ oynQExOZpUST84ExnlcSb2hiaG5paGRsYWFuZKQkzlvy4Uq4kEB6YklqdmpqQWoRTB8TB6dU A6NT5O2NyxTXpvevFr/Dw5Pn/rJiZ/5pc+UrYg0aKQE7HovLZ7KuvK26+hF7SraMep7Z7id3 T5jKGfa4Wryst7O8EOoyPciPIcCB+0BGYXzuouRov7MJJ9bXdGQ9aN7wVqi+KG3vi/sVTekZ p2eejJ3asn55hXfjt0m5bkcyj7gl6nwX57OMVGIpzkg01GIuKk4EAJjG5SC5AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161108145325eucas1p2f6e743dbfad6a4ea920d79284a524ebc X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20161107130625eucas1p2dd23c07010b4f3eddb6c6540ed802246 X-RootMTR: 20161107130625eucas1p2dd23c07010b4f3eddb6c6540ed802246 References: <1478523973-8828-1-git-send-email-m.szyprowski@samsung.com> <68e7a18b-739e-b73e-eacf-3cb6c1bd279a@arm.com> <8286728f-fab3-8179-5215-e156da426244@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, On 2016-11-08 15:44, Robin Murphy wrote: > On 08/11/16 13:41, Marek Szyprowski wrote: >> On 2016-11-08 12:37, Robin Murphy wrote: >>> On 07/11/16 13:06, Marek Szyprowski wrote: >>>> When one called iommu_dma_init_domain() with size smaller than device's >>>> DMA mask, the alloc_iova() will not respect it and always assume that >>>> all >>>> IOVA addresses will be allocated from the the (base ... >>>> dev->dma_mask) range. >>> Is that actually a problem for anything? >> Yes, I found this issue while working on next version of ARM & ARM64 >> DMA-mapping/IOMMU integration patchset and adapting Exynos drivers for the >> new IOMMU/DMA-mapping glue. >> >> Some Exynos devices (codec and camera isp) operate only on the limited (and >> really small: 256M for example) DMA window. They use non-standard way of >> addressing memory: an offset from the firmware base. However they still >> have >> 32bit DMA mask, as the firmware can be located basically everywhere in the >> real DMA address space, but then they can access only next 256M from that >> firmware base. > OK, that's good to know, thanks. However, I think in this case it sounds > like it's really the DMA mask that's the underlying problem - if those > blocks themselves can only drive 28 address bits, then the struct > devices representing them should have 28-bit DMA masks, and the > "firmware base" of whoever's driving the upper bits modelled with a > dma_pfn_offset. Even if they do have full 32-bit interfaces themselves, > but are constrained to segment-offset addressing internally, I still > think it would be tidier to represent things that way. > > At some point in dma-iommu development I did have support for DMA > offsets upstream of the IOMMU, and am happy to reinstate it if there's a > real use case (assuming you can't simply always set the firmware base to > 0 when using the IOMMU). That would indeed look a bit simpler, but I've already tried such approach and the firmware crashes when its base in real DMA address space is set to zero. >>>> This patch fixes this issue by taking the configured address space size >>>> parameter into account (if it is smaller than the device's dma_mask). >>> TBH I've been pondering ripping the size stuff out of dma-iommu, as it >>> all stems from me originally failing to understand what dma_32bit_pfn is >>> actually for. The truth is that iova_domains just don't have a size or >>> upper limit; however if devices with both large and small DMA masks >>> share a domain, then the top-down nature of the allocator means that >>> allocating for the less-capable devices would involve walking through >>> every out-of-range entry in the tree every time. Having cached32_node >>> based on dma_32bit_pfn just provides an optimised starting point for >>> searching within the smaller mask. >> Right, this dma_32bit_pfn was really misleading at the first glance, >> but then I found that this was something like end_pfn in case of dma-iommu >> code. > Yes, that was my incorrect assumption - at the time I interpreted it as > a de-facto upper limit which was still possible to allocate above in > special circumstances, which turns out to be almost entirely backwards. > I'd rather not bake that into the dma-iommu code any further if we can > avoid it (I'll try throwing an RFC together to clear up what's there > already). Okay. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland