From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Date: Tue, 13 Jan 2015 11:45:25 +0000 Message-ID: <54B50555.6090803@arm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: 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: Stefano Stabellini Cc: "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "arnd-r2nGTMty4D4@public.gmane.org" , Catalin Marinas , Will Deacon , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , "dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: iommu@lists.linux-foundation.org T24gMTMvMDEvMTUgMTE6MDgsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPiBPbiBNb24sIDEy IEphbiAyMDE1LCBSb2JpbiBNdXJwaHkgd3JvdGU6Cj4+IEhpIGFsbCwKPj4KPj4gV2hpbHN0IGl0 J3MgYSBsb25nIHdheSBvZmYgcGVyZmVjdCwgdGhpcyBoYXMgcmVhY2hlZCB0aGUgcG9pbnQgb2Yg YmVpbmcKPj4gZnVuY3Rpb25hbCBhbmQgc3RhYmxlIGVub3VnaCB0byBiZSB1c2VmdWwsIHNvIGhl cmUgaXQgaXMuIFRoZSBjb3JlCj4+IGNvbnNpc3RzIG9mIHRoZSBtZWF0IG9mIHRoZSBhcmNoL2Fy bSBpbXBsZW1lbnRhdGlvbiBtb2RpZmllZCB0byByZW1vdmUKPj4gdGhlIGFzc3VtcHRpb24gb2Yg UEFHRV9TSVpFIHBhZ2VzIGFuZCBwb3J0ZWQgb3ZlciB0byB0aGUgSW50ZWwgSU9WQQo+PiBhbGxv Y2F0b3IgaW5zdGVhZCBvZiB0aGUgYml0bWFwLWJhc2VkIG9uZS4gRm9yIHRoYXQsIHRoaXMgc2Vy aWVzIGRlcGVuZHMKPj4gb24gbXkgIkdlbmVyaWNpc2UgdGhlIElPVkEgYWxsb2NhdG9yIiBzZXJp ZXMgcG9zdGVkIGVhcmxpZXJbMV0uCj4+Cj4+IFRoZXJlIGFyZSBwbGVudHkgb2Ygb2J2aW91cyB0 aGluZ3Mgc3RpbGwgdG8gZG8sIGluY2x1ZGluZzoKPj4KPj4gICAqIERvbWFpbiBhbmQgZ3JvdXAg aGFuZGxpbmcgaXMgYWxsIHdyb25nLCBidXQgdGhhdCdzIGEgYmlnZ2VyIHByb2JsZW0uCj4+ICAg ICBGb3IgdGhlIG1vbWVudCBpdCBkb2VzIG1vcmUgb3IgbGVzcyB0aGUgc2FtZSB0aGluZyBhcyB0 aGUgYXJjaC9hcm0KPj4gICAgIGNvZGUsIHdoaWNoIGF0IGxlYXN0IHdvcmtzIGZvciB0aGUgb25l LUlPTU1VLXBlci1kZXZpY2Ugc2l0dWF0aW9uLgo+PiAgICogSU9NTVUgZG9tYWlucyBhbmQgSU9W QSBkb21haW5zIHByb2JhYmx5IHdhbnQgdG8gYmUgYmV0dGVyIGludGVncmF0ZWQKPj4gICAgIHdp dGggZGV2aWNlcyBhbmQgZWFjaCBvdGhlciwgcmF0aGVyIHRoYW4gaGF2aW5nIGEgcHJvbGlmZXJh dGlvbiBvZgo+PiAgICAgYXJjaC1zcGVjaWZpYyBzdHJ1Y3RzLgo+PiAgICogVGhlIHRlbXBvcmFy eSBtYXBfc2cgaW1wbGVtZW50YXRpb24gLSBJIGhhdmUgYSAncHJvcGVyJyBpb21tdV9tYXBfc2cK Pj4gICAgIGJhc2VkIG9uZSBpbiBwcm9ncmVzcywgYnV0IHNpbmNlIHRoZSBzaW1wbGUgb25lIHdv cmtzIGl0J3Mgbm90IGJlZW4KPj4gICAgIGFzIGhpZ2ggYSBwcmlvcml0eS4KPj4gICAqIFBvcnQg YXJjaC9hcm0gb3ZlciB0byBpdC4gSSdkIGd1ZXNzIGl0IG1pZ2h0IGJlIHByZWZlcmFibGUgdG8g bWVyZ2UKPj4gICAgIHRoaXMgdGhyb3VnaCBhcm02NCBmaXJzdCwgdGhvdWdoLCByYXRoZXIgdGhh biBvdmVyY29tcGxpY2F0ZSBtYXR0ZXJzLgo+PiAgICogVGhlcmUgbWF5IHdlbGwgYmUgc2NvcGUg Zm9yIHN0cmVhbWxpbmluZyBhbmQgdGlkeWluZyB1cCB0aGUgY29waWVkCj4+ICAgICBwYXJ0cyAt IEluIGdlbmVyYWwgSSd2ZSBzaW1wbHkgYXZvaWRlZCB0b3VjaGluZyBhbnl0aGluZyBJIGRvbid0 Cj4+ICAgICBmdWxseSB1bmRlcnN0YW5kLgo+PiAgICogSW4gdGhlIHNhbWUgdmVpbiwgSSdtIHN1 cmUgbG90cyBvZiBpdCBpcyBmYWlybHkgQVJNLXNwZWNpZmljLCBzbyB3aWxsCj4+ICAgICBuZWVk IGxvbmdlci10ZXJtIHdvcmsgdG8gYmVjb21lIHRydWx5IGdlbmVyaWMuCj4+Cj4+IFsxXTpodHRw Oi8vdGhyZWFkLmdtYW5lLm9yZy9nbWFuZS5saW51eC5rZXJuZWwuaW9tbXUvODIwOAo+Cj4gSSB0 cmllZCB0byBnaXQtYW0gYW5kIGJ1aWxkIGEgdjMuMTktcmM0IGtlcm5lbCB3aXRoIHRoaXMgc2Vy aWVzIChjb25maWcKPiBmaWxlIGF0dGFjaGVkKSwgYnV0IEkgZ2V0Ogo+Cj4gSW4gZmlsZSBpbmNs dWRlZCBmcm9tIGluY2x1ZGUvbGludXgvZG1hLW1hcHBpbmcuaDo4MjowLAo+ICAgICAgICAgICAg ICAgICAgIGZyb20gYXJjaC9hcm02NC9rZXJuZWwvYXNtLW9mZnNldHMuYzoyMzoKPiAuL2FyY2gv YXJtNjQvaW5jbHVkZS9hc20vZG1hLW1hcHBpbmcuaDogSW4gZnVuY3Rpb24g4oCYcGh5c190b19k bWHigJk6Cj4gLi9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL2RtYS1tYXBwaW5nLmg6Njk6MjogZXJy b3I6IOKAmHN0cnVjdCBkZXZfYXJjaGRhdGHigJkgaGFzIG5vIG1lbWJlciBuYW1lZCDigJhtYXBw aW5n4oCZCj4gLi9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL2RtYS1tYXBwaW5nLmg6IEluIGZ1bmN0 aW9uIOKAmGRtYV90b19waHlz4oCZOgo+IC4vYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9kbWEtbWFw cGluZy5oOjgxOjE5OiBlcnJvcjog4oCYc3RydWN0IGRldl9hcmNoZGF0YeKAmSBoYXMgbm8gbWVt YmVyIG5hbWVkIOKAmG1hcHBpbmfigJkKPiBtYWtlWzFdOiAqKiogW2FyY2gvYXJtNjQva2VybmVs L2FzbS1vZmZzZXRzLnNdIEVycm9yIDEKPgoKT29wcywgbG9va3MgbGlrZSBJJ3ZlIGJlZW4gcmVs eWluZyBvbiBoYXZpbmcgYW4gYWN0dWFsIElPTU1VIGRyaXZlciAKc2VsZWN0IENPTkZJR19JT01N VV9BUEkgLSBlbmFibGluZyB0aGUgQVJNIFNNTVUgZHJpdmVyIGFzIHdlbGwgYXMgIklPTU1VIApo YXJkd2FyZSBzdXBwb3J0IiBtYWtlcyBldmVyeXRoaW5nIGJ1aWxkLCBldmVuIGlmIGl0IGRvZXNu J3QgYWN0dWFsbHkgCndvcmsgd2l0aCB0aGUgbmV3IGZyYW1ld29yayAodGhlIHBhdGNoZXMgZm9y IHRoYXQgZXhpc3QsIGJ1dCBhcmUgCmN1cnJlbnRseSBhIGJpZyB1Z2x5IG1lc3MpLgoKVGhlIG5l c3RlZCAjaW5jbHVkZSBndWFyZCBpbiBhcmNoL2FybTY0L2luY2x1ZGUvYXNtL2RldmljZS5oIGlu IHBhdGNoIDQgCmlzIHRvIGJsYW1lIC0gb24gcmVmbGVjdGlvbiwgSSBndWVzcyB0aGF0IGlzbid0 IGEgZ3JlYXQgaWRlYSByZWdhcmRsZXNzIApvZiB0aGUgbG9naWNhbCBkZXBlbmRlbmN5IChJIGRv bid0IHRoaW5rIG15IEtjb25maWctZnUgaXMgc3Ryb25nIGVub3VnaCAKdG8gZ3VhcmFudGVlIHRo YXQgZGVwZW5kZW5jeSBpcyBlbmZvcmNlZCkuCgpSb2Jpbi4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmlvbW11IG1haWxpbmcgbGlzdAppb21tdUBsaXN0 cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcv bWFpbG1hbi9saXN0aW5mby9pb21tdQ== From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Tue, 13 Jan 2015 11:45:25 +0000 Subject: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping In-Reply-To: References: Message-ID: <54B50555.6090803@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 13/01/15 11:08, Stefano Stabellini wrote: > On Mon, 12 Jan 2015, Robin Murphy wrote: >> Hi all, >> >> Whilst it's a long way off perfect, this has reached the point of being >> functional and stable enough to be useful, so here it is. The core >> consists of the meat of the arch/arm implementation modified to remove >> the assumption of PAGE_SIZE pages and ported over to the Intel IOVA >> allocator instead of the bitmap-based one. For that, this series depends >> on my "Genericise the IOVA allocator" series posted earlier[1]. >> >> There are plenty of obvious things still to do, including: >> >> * Domain and group handling is all wrong, but that's a bigger problem. >> For the moment it does more or less the same thing as the arch/arm >> code, which at least works for the one-IOMMU-per-device situation. >> * IOMMU domains and IOVA domains probably want to be better integrated >> with devices and each other, rather than having a proliferation of >> arch-specific structs. >> * The temporary map_sg implementation - I have a 'proper' iommu_map_sg >> based one in progress, but since the simple one works it's not been >> as high a priority. >> * Port arch/arm over to it. I'd guess it might be preferable to merge >> this through arm64 first, though, rather than overcomplicate matters. >> * There may well be scope for streamlining and tidying up the copied >> parts - In general I've simply avoided touching anything I don't >> fully understand. >> * In the same vein, I'm sure lots of it is fairly ARM-specific, so will >> need longer-term work to become truly generic. >> >> [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208 > > I tried to git-am and build a v3.19-rc4 kernel with this series (config > file attached), but I get: > > In file included from include/linux/dma-mapping.h:82:0, > from arch/arm64/kernel/asm-offsets.c:23: > ./arch/arm64/include/asm/dma-mapping.h: In function ?phys_to_dma?: > ./arch/arm64/include/asm/dma-mapping.h:69:2: error: ?struct dev_archdata? has no member named ?mapping? > ./arch/arm64/include/asm/dma-mapping.h: In function ?dma_to_phys?: > ./arch/arm64/include/asm/dma-mapping.h:81:19: error: ?struct dev_archdata? has no member named ?mapping? > make[1]: *** [arch/arm64/kernel/asm-offsets.s] Error 1 > Oops, looks like I've been relying on having an actual IOMMU driver select CONFIG_IOMMU_API - enabling the ARM SMMU driver as well as "IOMMU hardware support" makes everything build, even if it doesn't actually work with the new framework (the patches for that exist, but are currently a big ugly mess). The nested #include guard in arch/arm64/include/asm/device.h in patch 4 is to blame - on reflection, I guess that isn't a great idea regardless of the logical dependency (I don't think my Kconfig-fu is strong enough to guarantee that dependency is enforced). Robin.