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: Fri, 16 Jan 2015 20:12:29 +0000 Message-ID: <54B970AD.7020407@arm.com> References: <1421136128.27675.58.camel@mtksdaap41> <54B80857.7060407@arm.com> <1421392892.19175.6.camel@mhfsdcap03> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1421392892.19175.6.camel@mhfsdcap03> 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: Yong Wu Cc: "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "arnd-r2nGTMty4D4@public.gmane.org" , "stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org" , Catalin Marinas , "thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , Will Deacon , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Yingjoe Chen , "eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" , "dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: iommu@lists.linux-foundation.org T24gMTYvMDEvMTUgMDc6MjEsIFlvbmcgV3Ugd3JvdGU6ClsuLi5dCj4+IE5vdyB0aGF0IHRoZSBz ZXJ2ZXIgc2VlbXMgdG8gYmUgcHJvcGVybHkgYWNjZXNzaWJsZSBhZ2FpbiwgSSd2ZSBtYWRlIGEK Pj4gYnJhbmNoIHdpdGggYm90aCBzZXJpZXMgYXZhaWxhYmxlIGhlcmU6Cj4+Cj4+ICAgICBnaXQ6 Ly9saW51eC1hcm0ub3JnL2xpbnV4LXJtIGlvbW11L2RtYQo+Pgo+PiBOb3RlIHRoYXQgaW4gdGhl IGN1cnJlbnQgc3RhdGUgaXQgYWxzbyBkZXBlbmRzIG9uIGhhdmluZyB0aGUgQVJNIFNNTVUKPj4g ZHJpdmVyIHNlbGVjdGVkIGluIHRoZSBjb25maWcsIGR1ZSB0byBhbiBvdmVyc2lnaHQgb24gbXkg cGFydCA6KAo+Pgo+PiBSb2Jpbi4KPj4KPiBEZWFyIFJvYmluLAo+Cj4gICAgICAgV2UgaGF2ZSB0 ZXN0IHRoaXMgcGF0Y2ggb24gb3VyIFNPQyhtdDgxNzMpLHdoaWNoIGhhdmUgb3VyIG93biBpb21t dQo+IEhXKGl0IGlzIG5vdCBBUk0gU01NVSksIHRoZSBwYXRjaCBjb3VsZCB3b3JrIHdlbGwuCj4g VGVzdGVkLWJ5OllvbmcgV3UgPHlvbmcud3VAbWVkaWF0ZWsuY29tPgo+CgpUaGFua3MhCgo+ICAg QW5kIEkgaGF2ZSBzb21lIHF1ZXN0aW9uZXMgYWJvdXQgdGhlIHVzYWdlOgo+Cj4gMSkgSWYgd2Ug Y3JlYXRlIGEgaW9tbXUgZG9tYWluIGJ5IOKAnGFyY2hfc2V0dXBfZG1hX29wcyIsIHRoZW4gd2Ug d291bGQKPiBsaWtlIHRvIGNhbGwgdGhlIHN0YW5kYXJkIGlvbW11IGludGVyZmFjZSwgbGlrZQo+ IOKAnGlvbW11X3NldF9mYXVsdF9oYW5kbGXigJ0sCj4gSG93IGNhbiB3ZSBnZXQgdGhlICJzdHJ1 Y3QgaW9tbXVfZG9tYWluICoiPyAodGhlIOKAnGRldl9kb21haW7igJ0gaXMKPiBzdGF0aWMuKQo+ Cj4gMikgSWYgYSBkZXZpY2UgQSBjYWxsIOKAnGFyY2hfc2V0dXBfZG1hX29wc+KAnSB0byBjcmVh dGUgYSBpb21tdSBkb21haW4sIGFuZAo+IGEgY2xpZW50IGRldmljZSBCIHdvdWxkIGxpa2UgdG8g am9pbiB0aGlzIGlvbW11IGRvbWFpbiwKPiBzbyBpdCBjYWxsIOKAnGlvbW11X2RtYV9hdHRhY2hf ZGV2aWNl4oCdLiB0aGVuIHRoZSBkZXZpY2UgQiB3YW50IHRvIGFsbG9jCj4gdGhlIGlvbW11IG1l bW9yeSwgaXQgY2FsbCDigJxkbWFfYWxsb2NfYXR0cnPigJ0gd2hvc2UgZmlyc3QgcGFyYW1ldGVy IHNob3VsZAo+IGJlIHRoZSDigJxzdHJ1Y3QgZGV2aWNlICrigJ1vZiBkZXZpY2UgQS4gSXMgaXQg ZGVzaWduZWQgbGlrZSB0aGlzIGluIHRoaXMKPiBwYXRjaD8KPiAgICAgIChJbiBhcmNoL2FybSwg 4oCcZGV2LT5hcmNoZGF0YS5kbWFfb3BzID0gJmlvbW11X2RtYV9vcHPigJ0gaXMgaW4KPiDigJxh cm1faW9tbXVfYXR0YWNoX2RldmNl4oCdOwo+ICAgICAgIEluIHRoaXMgcGF0Y2gsIHRoaXMgc2Vu dGVuY2UgaXMgaW4g4oCcYXJjaF9zZXR1cF9kbWFfb3Bz4oCdKS4KPgoKQXQgdGhpcyBwb2ludCB0 aGVyZSdzIG5vdCByZWFsbHkgYW55IHN1cHBvcnQgZm9yIGRldmljZXMgbWFuYWdpbmcgdGhlaXIg Cm93biBJT01NVXMgLSBpbml0aWFsbHkgSSd2ZSBvbmx5IGJlZW4gZm9jdXNpbmcgb24gdGhlIGNh c2Ugd2hlcmUgCmRtYS1tYXBwaW5nIGhhbmRsZXMgZXZlcnl0aGluZyB0cmFuc3BhcmVudGx5LCB3 aXRoIGxlZ2FjeSAzMi1iaXQgCnBlcmlwaGVyYWxzIGluIG1pbmQuIFRoZXJlJ3MgYWxyZWFkeSBi ZWVuIHF1aXRlIGEgbG90IG9mIGRpc2N1c3Npb24gb3ZlciAKdGhlIHNob3J0Y29taW5ncyBvZiB0 aGUgY3VycmVudCBhcmNoX3NldHVwX2RtYV9vcHMgbW9kZWwgKG1vc3QgcmVjZW50bHksIApbMV0p LCBidXQgaXQganVzdC1hYm91dC13b3JrcyBvbiBKdW5vIHdoZXJlIHdlIGhhdmUgYSBzaW5nbGUg ZGV2aWNlIApiZWhpbmQgZWFjaCBJT01NVSAod2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBVU0Ig T0hDSSB3aGljaCBmYWxscyBmb3VsIApvZiB0aGUgZG9tYWluLXBlci1kZXZpY2UgYXBwcm9hY2gg YW5kIGZhbGxzIG92ZXIgYmVjYXVzZSBpdCBjYW4ndCAKdW5kZXJzdGFuZCBhZGRyZXNzZXMgZnJv bSB0aGUgRUhDSSkuIFdlIHJlYWxseSBuZWVkIHRvIGdldCBJT01NVSBncm91cHMgCndvcmtpbmcg aW4gb3JkZXIgdG8gbWFuYWdlIGRvbWFpbnMgcHJvcGVybHksIHdoaWNoIGZvciBvbmUgdGhpbmcg CnJlcXVpcmVzIGZpeGluZyB0aGUgY3VycmVudCBzaXR1YXRpb24gb2YgZGV2aWNlcyBnZXR0aW5n IGF0dGFjaGVkIHRvIGEgCmRvbWFpbiBiZWZvcmUgdGhleSd2ZSBldmVuIGJlZW4gYWRkZWQgdG8g dGhlIGJ1cy4gSSd2ZSBzdGFydGVkIGxvb2tpbmcgCmludG8gdGhhdCwgYnV0IEkgc3VzcGVjdCBp dCdzIGdvaW5nIHRvIGJlIGxvbmcgYW5kIGNvbXBsaWNhdGVkLgoKPiAzKSAgdm9pZCBhcmNoX3Nl dHVwX2RtYV9vcHMoc3RydWN0IGRldmljZSAqZGV2LCB1NjQgZG1hX2Jhc2UsIHU2NCBzaXplLAo+ IHN0cnVjdCBpb21tdV9vcHMgKmlvbW11LCBib29sIGNvaGVyZW50KQo+ICAgICAgSW4gdGhpcyBm dW5jdGlvbiwgdGhlIHNlY29uZCBhbmQgdGhpcmQgcGFyYW1ldGVyIGFyZSB0aGUgZG1hIGFkZHJl c3MKPiBiYXNlIGFuZCBzaXplLCBjYW4gdGhleSB3b3JrIGN1cnJlbnRseT8KPiAodGFrZSBhIGV4 YW1wbGUsIEkgc2V0IHRoZSBkbWFfYmFzZSBpcyAwLCBzaXplIGlzIDB4NDAwMDAwMDAgd2hpbGUK PiBjYWxsaW5nIGFyY2hfc2V0dXBfZG1hX29wcywKPiAgIHRoZW4gSSBhbGxvYyBhIHJhbmdlIGlv dmEgd2hvc2Ugc2l6ZSBpcyA1MCpTWl80SywgdGhlIHJldHVybiBpb3ZhIGlzCj4gMHhmZmZjZTAw MCwgaXQgaXMgb3ZlciAweDQwMDAwMDAwLikKPgoKVGhhdCdsbCBiZSBjb21pbmcgZnJvbSBfX2Fs bG9jX2lvdmEgdXNpbmcgdGhlIGRldmljZSdzIGRtYV9tYXNrIGFzIGFuIAp1cHBlciBsaW1pdC4g V2hpbHN0IEknbSBub3Qgc3VyZSBpZiBoYXZpbmcgZml4ZWQgdHJhbnNsYXRpb25zIHBlciAKZG1h LXJhbmdlcyBtYWtlcyBzZW5zZSB3aXRoIGFuIElPTU1VIHByZXNlbnQsIHRoZXJlIGRvZXMgc2Vl bSB0byBiZSBhIAp2YWxpZCBjYXNlIGZvciBoYXZpbmcgYSBzaXplIHNtYWxsZXIgdGhhbiB0aGUg ZHJpdmVyJ3MgZG1hX21hc2sgLSBlLmcuIGEgCmRldmljZSB0aGF0IGp1c3QgaGFwcGVucyB0byBo YXZlIHNvbWUgdXBwZXIgYWRkcmVzcyBsaW5lcyB0aWVkIG9mZiBpbiBhIApwYXJ0aWN1bGFyIGlt cGxlbWVudGF0aW9uIC0gc28gSSdsbCBjaGFuZ2UgdGhhdCB0byBwcm9wZXJseSByZXNwZWN0IHRo ZSAKZG1hLXJhbmdlcyB2YWx1ZXMuCgpSb2Jpbi4KClsxXTpodHRwOi8vdGhyZWFkLmdtYW5lLm9y Zy9nbWFuZS5saW51eC5rZXJuZWwuaW9tbXUvNzU1Ni9mb2N1cz04MjM3CgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaW9tbXUgbWFpbGluZyBsaXN0Cmlv bW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0 aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvbW11 From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Fri, 16 Jan 2015 20:12:29 +0000 Subject: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping In-Reply-To: <1421392892.19175.6.camel@mhfsdcap03> References: <1421136128.27675.58.camel@mtksdaap41> <54B80857.7060407@arm.com> <1421392892.19175.6.camel@mhfsdcap03> Message-ID: <54B970AD.7020407@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 16/01/15 07:21, Yong Wu wrote: [...] >> Now that the server seems to be properly accessible again, I've made a >> branch with both series available here: >> >> git://linux-arm.org/linux-rm iommu/dma >> >> Note that in the current state it also depends on having the ARM SMMU >> driver selected in the config, due to an oversight on my part :( >> >> Robin. >> > Dear Robin, > > We have test this patch on our SOC(mt8173),which have our own iommu > HW(it is not ARM SMMU), the patch could work well. > Tested-by:Yong Wu > Thanks! > And I have some questiones about the usage: > > 1) If we create a iommu domain by ?arch_setup_dma_ops", then we would > like to call the standard iommu interface, like > ?iommu_set_fault_handle?, > How can we get the "struct iommu_domain *"? (the ?dev_domain? is > static.) > > 2) If a device A call ?arch_setup_dma_ops? to create a iommu domain, and > a client device B would like to join this iommu domain, > so it call ?iommu_dma_attach_device?. then the device B want to alloc > the iommu memory, it call ?dma_alloc_attrs? whose first parameter should > be the ?struct device *?of device A. Is it designed like this in this > patch? > (In arch/arm, ?dev->archdata.dma_ops = &iommu_dma_ops? is in > ?arm_iommu_attach_devce?; > In this patch, this sentence is in ?arch_setup_dma_ops?). > At this point there's not really any support for devices managing their own IOMMUs - initially I've only been focusing on the case where dma-mapping handles everything transparently, with legacy 32-bit peripherals in mind. There's already been quite a lot of discussion over the shortcomings of the current arch_setup_dma_ops model (most recently, [1]), but it just-about-works on Juno where we have a single device behind each IOMMU (with the exception of the USB OHCI which falls foul of the domain-per-device approach and falls over because it can't understand addresses from the EHCI). We really need to get IOMMU groups working in order to manage domains properly, which for one thing requires fixing the current situation of devices getting attached to a domain before they've even been added to the bus. I've started looking into that, but I suspect it's going to be long and complicated. > 3) void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, > struct iommu_ops *iommu, bool coherent) > In this function, the second and third parameter are the dma address > base and size, can they work currently? > (take a example, I set the dma_base is 0, size is 0x40000000 while > calling arch_setup_dma_ops, > then I alloc a range iova whose size is 50*SZ_4K, the return iova is > 0xfffce000, it is over 0x40000000.) > That'll be coming from __alloc_iova using the device's dma_mask as an upper limit. Whilst I'm not sure if having fixed translations per dma-ranges makes sense with an IOMMU present, there does seem to be a valid case for having a size smaller than the driver's dma_mask - e.g. a device that just happens to have some upper address lines tied off in a particular implementation - so I'll change that to properly respect the dma-ranges values. Robin. [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7556/focus=8237