From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Herrmann Subject: Re: [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings Date: Thu, 23 Jan 2014 22:50:46 +0100 Message-ID: <20140123215046.GF26399@alberich> References: <1389876263-25759-1-git-send-email-andreas.herrmann@calxeda.com> <1389876263-25759-12-git-send-email-andreas.herrmann@calxeda.com> <20140122161010.GH14108@mudshark.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20140122161010.GH14108-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@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: Will Deacon Cc: Nicolas Pitre , Russell King , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Andreas Herrmann , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: iommu@lists.linux-foundation.org T24gV2VkLCBKYW4gMjIsIDIwMTQgYXQgMDQ6MTA6MTFQTSArMDAwMCwgV2lsbCBEZWFjb24gd3Jv dGU6Cj4gT24gVGh1LCBKYW4gMTYsIDIwMTQgYXQgMTI6NDQ6MjNQTSArMDAwMCwgQW5kcmVhcyBI ZXJybWFubiB3cm90ZToKPiA+IEluc3RlYWQgb2YgdXNpbmcganVzdCBvbmUgYml0bWFwIHRvIGtl ZXAgdHJhY2sgb2YgSU8gdmlydHVhbCBhZGRyZXNzZXMKPiA+IChoYW5kZWQgb3V0IGZvciBJT01N VSB1c2UpIGludHJvZHVjZSBhIGxpc3Qgb2YgaW92YV9yYW5nZXMgKGVhY2gKPiA+IGhhdmluZyBp dHMgb3duIGJpdG1hcCkuIFRoaXMgYWxsb3dzIHVzIHRvIGV4dGVuZCBleGlzdGluZyBtYXBwaW5n cwo+ID4gd2hlbiBydW5uaW5nIG91dCBvZiBpb3ZhIHNwYWNlIGZvciBhIG1hcHBpbmcuCj4gPiAK PiA+IElmIHRoZXJlIGlzIG5vdCBlbm91Z2ggc3BhY2UgaW4gdGhlIG1hcHBpbmcgdG8gc2Vydmlj ZSBhbiBJTyB2aXJ0dWFsCj4gPiBhZGRyZXNzIGFsbG9jYXRpb24gcmVxdWVzdCwgX19hbGxvY19p b3ZhKCkgdHJpZXMgdG8gZXh0ZW5kIHRoZSBtYXBwaW5nCj4gPiAtLSBieSBhbGxvY2F0aW5nIGFu b3RoZXIgYml0bWFwIC0tIGFuZCBtYWtlcyBhbm90aGVyIGFsbG9jYXRpb24KPiA+IGF0dGVtcHQg dXNpbmcgdGhlIGZyZXNobHkgYWxsb2NhdGVkIGJpdG1hcC4KPiA+IAo+ID4gVGhpcyBhbGxvd3Mg YXJtIGlvbW11IGRyaXZlcnMgdG8gc3RhcnQgd2l0aCBhIGRlY2VudCBpbml0aWFsIHNpemUgd2hl bgo+ID4gYW4gZG1hX2lvbW11X21hcHBpbmcgaXMgY3JlYXRlZCBhbmQgc3RpbGwgdG8gYXZvaWQg cnVubmluZyBvdXQgb2YgSU8KPiA+IHZpcnR1YWwgYWRkcmVzc2VzIGZvciB0aGUgbWFwcGluZy4K PiA+IAo+ID4gVGVzdHMgd2VyZSBkb25lIG9uIENhbHhlZGEgRUNYLTIwMDAgd2l0aCBzbW11IGZv ciBzYXRhIGFuZCB4Z21hYy4KPiA+IEkndmUgdXNlZCBTWl81MTJLIGJvdGggZm9yIGluaXRpYWwg bWFwcGluZyBzaXplIGFuZCBncm93X3NpemUuCj4gCj4gQWhhLCBJIHRob3VnaHQgZ3Jvd19zaXpl IHdhcyB0aGUgKm1heGltdW0qIHNpemUsIHJhdGhlciB0aGFuIHRoZSBpbmNyZW1lbnRhbAo+IHNp emUuIEluIHdoaWNoIGNhc2UsIHlvdSBwcm9iYWJseSB3YW50IHRvIHBpY2sgdGhlIG1heGltdW0g c3VwcG9ydGVkIElPTU1VCj4gcGFnZSBzaXplIHRoYXQgc2F0aXNmaWVzIGEgZml4ZWQgbGltaXQg b24gdGhlIGJpdG1hcCBzaXplLgo+IAo+ID4gK3N0YXRpYyBpbnQgZXh0ZW5kX2lvbW11X21hcHBp bmcoc3RydWN0IGRtYV9pb21tdV9tYXBwaW5nICptYXBwaW5nKQo+ID4gK3sKPiA+ICsJc3RydWN0 IGRtYV9pb21tdV9pb3ZhX3JhbmdlICppb3ZhcjsKPiA+ICsJdW5zaWduZWQgaW50IGNvdW50ID0g bWFwcGluZy0+Z3Jvd19zaXplID4+IChQQUdFX1NISUZUICsgbWFwcGluZy0+b3JkZXIpOwo+ID4g Kwl1bnNpZ25lZCBpbnQgYml0bWFwX3NpemUgPSBCSVRTX1RPX0xPTkdTKGNvdW50KSAqIHNpemVv Zihsb25nKTsKPiA+ICsKPiA+ICsJaWYgKCFtYXBwaW5nLT5ncm93X3NpemUgfHwKPiA+ICsJCSht YXBwaW5nLT5zaXplICsgbWFwcGluZy0+Z3Jvd19zaXplKSA+PSBtYXBwaW5nLT5tYXhfc2l6ZSkK PiA+ICsJCXJldHVybiAtRUlOVkFMOwo+ID4gKwo+ID4gKwlpb3ZhciA9IGt6YWxsb2Moc2l6ZW9m KHN0cnVjdCBkbWFfaW9tbXVfaW92YV9yYW5nZSksIEdGUF9BVE9NSUMpOwo+ID4gKwlpZiAoIWlv dmFyKQo+ID4gKwkJcmV0dXJuIC1FTk9NRU07Cj4gPiArCj4gPiArCWlvdmFyLT5iaXRtYXAgPSBr emFsbG9jKGJpdG1hcF9zaXplLCBHRlBfQVRPTUlDKTsKPiAKPiBEbyB0aGVzZSBhbGxvY2F0aW9u IHJlYWxseSBuZWVkIHRvIGJlIGF0b21pYz8gSSB3b3JyeSB0aGF0J3MgZ29pbmcgdG8gaGF2ZQo+ IHNldmVyZSByZXN0cmljdGlvbnMgb24gb3VyIGFiaWxpdHkgdG8gYWxsb2NhdGUgbGFyZ2UgYWRk cmVzcyBzcGFjZXMuCgpTYXkgc29tZSBjb2RlIGFjcXVpcmVkIGEgbG9jayBiZWZvcmUgY2FsbGlu ZyBkbWFfbWFwX3NpbmdsZS4KSWYgd2UgaGF2ZSB0byBleHRlbmQgdGhlIG1hcHBpbmcgaW4gc3Vj aCBhIHBhdGggd2Ugc2hvdWxkIG5vdCBzxLplZXAuCgoKQW5kcmVhcwpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwppb21tdSBtYWlsaW5nIGxpc3QKaW9tbXVA bGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24u b3JnL21haWxtYW4vbGlzdGluZm8vaW9tbXU= From mboxrd@z Thu Jan 1 00:00:00 1970 From: herrmann.der.user@googlemail.com (Andreas Herrmann) Date: Thu, 23 Jan 2014 22:50:46 +0100 Subject: [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings In-Reply-To: <20140122161010.GH14108@mudshark.cambridge.arm.com> References: <1389876263-25759-1-git-send-email-andreas.herrmann@calxeda.com> <1389876263-25759-12-git-send-email-andreas.herrmann@calxeda.com> <20140122161010.GH14108@mudshark.cambridge.arm.com> Message-ID: <20140123215046.GF26399@alberich> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Jan 22, 2014 at 04:10:11PM +0000, Will Deacon wrote: > On Thu, Jan 16, 2014 at 12:44:23PM +0000, Andreas Herrmann wrote: > > Instead of using just one bitmap to keep track of IO virtual addresses > > (handed out for IOMMU use) introduce a list of iova_ranges (each > > having its own bitmap). This allows us to extend existing mappings > > when running out of iova space for a mapping. > > > > If there is not enough space in the mapping to service an IO virtual > > address allocation request, __alloc_iova() tries to extend the mapping > > -- by allocating another bitmap -- and makes another allocation > > attempt using the freshly allocated bitmap. > > > > This allows arm iommu drivers to start with a decent initial size when > > an dma_iommu_mapping is created and still to avoid running out of IO > > virtual addresses for the mapping. > > > > Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac. > > I've used SZ_512K both for initial mapping size and grow_size. > > Aha, I thought grow_size was the *maximum* size, rather than the incremental > size. In which case, you probably want to pick the maximum supported IOMMU > page size that satisfies a fixed limit on the bitmap size. > > > +static int extend_iommu_mapping(struct dma_iommu_mapping *mapping) > > +{ > > + struct dma_iommu_iova_range *iovar; > > + unsigned int count = mapping->grow_size >> (PAGE_SHIFT + mapping->order); > > + unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long); > > + > > + if (!mapping->grow_size || > > + (mapping->size + mapping->grow_size) >= mapping->max_size) > > + return -EINVAL; > > + > > + iovar = kzalloc(sizeof(struct dma_iommu_iova_range), GFP_ATOMIC); > > + if (!iovar) > > + return -ENOMEM; > > + > > + iovar->bitmap = kzalloc(bitmap_size, GFP_ATOMIC); > > Do these allocation really need to be atomic? I worry that's going to have > severe restrictions on our ability to allocate large address spaces. Say some code acquired a lock before calling dma_map_single. If we have to extend the mapping in such a path we should not s?eep. Andreas