From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA1A0C43382 for ; Tue, 25 Sep 2018 10:32:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 90AE72145D for ; Tue, 25 Sep 2018 10:32:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90AE72145D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-pci-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726586AbeIYQjr (ORCPT ); Tue, 25 Sep 2018 12:39:47 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48670 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726125AbeIYQjr (ORCPT ); Tue, 25 Sep 2018 12:39:47 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BF4CC7A9; Tue, 25 Sep 2018 03:32:52 -0700 (PDT) Received: from [10.4.12.111] (ostrya.emea.arm.com [10.4.12.111]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 43EA63F5B7; Tue, 25 Sep 2018 03:32:49 -0700 (PDT) Subject: Re: [PATCH v3 03/10] iommu/sva: Manage process address spaces To: Lu Baolu , "iommu@lists.linux-foundation.org" Cc: "joro@8bytes.org" , "linux-pci@vger.kernel.org" , "jcrouse@codeaurora.org" , "alex.williamson@redhat.com" , "Jonathan.Cameron@huawei.com" , "jacob.jun.pan@linux.intel.com" , "christian.koenig@amd.com" , "eric.auger@redhat.com" , "kevin.tian@intel.com" , "yi.l.liu@intel.com" , Andrew Murray , Will Deacon , Robin Murphy , "ashok.raj@intel.com" , "xuzaibo@huawei.com" , "liguozhu@hisilicon.com" , "okaya@codeaurora.org" , "bharatku@xilinx.com" , "ilias.apalodimas@linaro.org" , "shunyong.yang@hxt-semitech.com" References: <20180920170046.20154-1-jean-philippe.brucker@arm.com> <20180920170046.20154-4-jean-philippe.brucker@arm.com> <09933fce-b959-32e1-b1f3-0d4389abf735@linux.intel.com> From: Jean-Philippe Brucker Message-ID: <5aff8dc0-9ce7-5018-e78e-770279681cbc@arm.com> Date: Tue, 25 Sep 2018 11:32:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <09933fce-b959-32e1-b1f3-0d4389abf735@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On 25/09/2018 04:15, Lu Baolu wrote: >> +     /* If an io_mm already exists, use it */ >> +     spin_lock(&iommu_sva_lock); >> +     idr_for_each_entry(&iommu_pasid_idr, io_mm, i) { > > This might be problematic for vt-d (and other possible arch's which use > PASID other than SVA). When vt-d iommu works in scalable mode, a PASID > might be allocated for: > > (1) SVA > (2) Device Assignable Interface (might be a mdev or directly managed >      within a device driver). > (3) SVA in VM guest > (4) Device Assignable Interface in VM guest > > So we can't expect that an io_mm pointer was associated with each PASID. Yes as discussed on the previous series, we'll need to move the PASID allocator outside of iommu-sva at some point, and even outside of drivers/iommu since device driver might want to use the PASID allocator without an IOMMU. To be usable by all consumers of PASIDs, that allocator will need the same interface as IDR, so I don't think we have a problem here. I haven't had time or need to write such allocator yet (and don't plan to do it as part of this series), but I drafted an interface, that at least fulfills the needs of SVA. * Single system-wide PASID space * Multiple consumers, each associating their own structure to PASIDs. Each consumer gets a token. * Device drivers might want to use both SVA and private PASIDs for a device at the same time. * In my opinion "pasid" isn't the right name, "ioasid" would be better but that's not important. typedef unsigned int pasid_t; /* Returns consumer token */ void *pasid_get_consumer(); void pasid_put_consumer(void *consumer); /* Returns pasid or invalid (pasid_t)(-1) */ pasid_t pasid_alloc(void *consumer, pasid_t min, pasid_t max, void *private); void pasid_remove(pasid_t pasid); /* Iterate over PASIDs for this consumer. Func returns non-zero to stop iterating */ int pasid_for_each(void *consumer, void *iter_data, int (*func)(void *iter_data, pasid_t pasid, void *private)); /* Returns priv data or NULL */ void *pasid_find(void *consumer, pasid_t pasid); Thanks, Jean > And this code might run into problem if the pasid is allocated for > usages other than SVA. > > Best regards, > Lu Baolu From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Philippe Brucker Subject: Re: [PATCH v3 03/10] iommu/sva: Manage process address spaces Date: Tue, 25 Sep 2018 11:32:32 +0100 Message-ID: <5aff8dc0-9ce7-5018-e78e-770279681cbc@arm.com> References: <20180920170046.20154-1-jean-philippe.brucker@arm.com> <20180920170046.20154-4-jean-philippe.brucker@arm.com> <09933fce-b959-32e1-b1f3-0d4389abf735@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <09933fce-b959-32e1-b1f3-0d4389abf735-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> Content-Language: en-US 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: Lu Baolu , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" Cc: "kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , Will Deacon , "okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org" , "alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "liguozhu-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org" , Robin Murphy , "christian.koenig-5C7GfCeVMHo@public.gmane.org" List-Id: iommu@lists.linux-foundation.org T24gMjUvMDkvMjAxOCAwNDoxNSwgTHUgQmFvbHUgd3JvdGU6Cj4+ICvCoMKgwqDCoCAvKiBJZiBh biBpb19tbSBhbHJlYWR5IGV4aXN0cywgdXNlIGl0ICovCj4+ICvCoMKgwqDCoCBzcGluX2xvY2so JmlvbW11X3N2YV9sb2NrKTsKPj4gK8KgwqDCoMKgIGlkcl9mb3JfZWFjaF9lbnRyeSgmaW9tbXVf cGFzaWRfaWRyLCBpb19tbSwgaSkgewo+IAo+IFRoaXMgbWlnaHQgYmUgcHJvYmxlbWF0aWMgZm9y IHZ0LWQgKGFuZCBvdGhlciBwb3NzaWJsZSBhcmNoJ3Mgd2hpY2ggdXNlCj4gUEFTSUQgb3RoZXIg dGhhbiBTVkEpLiBXaGVuIHZ0LWQgaW9tbXUgd29ya3MgaW4gc2NhbGFibGUgbW9kZSwgYSBQQVNJ RAo+IG1pZ2h0IGJlIGFsbG9jYXRlZCBmb3I6Cj4gCj4gKDEpIFNWQQo+ICgyKSBEZXZpY2UgQXNz aWduYWJsZSBJbnRlcmZhY2UgKG1pZ2h0IGJlIGEgbWRldiBvciBkaXJlY3RseSBtYW5hZ2VkCj4g wqDCoMKgwqAgd2l0aGluIGEgZGV2aWNlIGRyaXZlcikuCj4gKDMpIFNWQSBpbiBWTSBndWVzdAo+ ICg0KSBEZXZpY2UgQXNzaWduYWJsZSBJbnRlcmZhY2UgaW4gVk0gZ3Vlc3QKPiAKPiBTbyB3ZSBj YW4ndCBleHBlY3QgdGhhdCBhbiBpb19tbSBwb2ludGVyIHdhcyBhc3NvY2lhdGVkIHdpdGggZWFj aCBQQVNJRC4KClllcyBhcyBkaXNjdXNzZWQgb24gdGhlIHByZXZpb3VzIHNlcmllcywgd2UnbGwg bmVlZCB0byBtb3ZlIHRoZSBQQVNJRAphbGxvY2F0b3Igb3V0c2lkZSBvZiBpb21tdS1zdmEgYXQg c29tZSBwb2ludCwgYW5kIGV2ZW4gb3V0c2lkZSBvZgpkcml2ZXJzL2lvbW11IHNpbmNlIGRldmlj ZSBkcml2ZXIgbWlnaHQgd2FudCB0byB1c2UgdGhlIFBBU0lEIGFsbG9jYXRvcgp3aXRob3V0IGFu IElPTU1VLgoKVG8gYmUgdXNhYmxlIGJ5IGFsbCBjb25zdW1lcnMgb2YgUEFTSURzLCB0aGF0IGFs bG9jYXRvciB3aWxsIG5lZWQgdGhlCnNhbWUgaW50ZXJmYWNlIGFzIElEUiwgc28gSSBkb24ndCB0 aGluayB3ZSBoYXZlIGEgcHJvYmxlbSBoZXJlLiBJCmhhdmVuJ3QgaGFkIHRpbWUgb3IgbmVlZCB0 byB3cml0ZSBzdWNoIGFsbG9jYXRvciB5ZXQgKGFuZCBkb24ndCBwbGFuIHRvCmRvIGl0IGFzIHBh cnQgb2YgdGhpcyBzZXJpZXMpLCBidXQgSSBkcmFmdGVkIGFuIGludGVyZmFjZSwgdGhhdCBhdCBs ZWFzdApmdWxmaWxscyB0aGUgbmVlZHMgb2YgU1ZBLgoKKiBTaW5nbGUgc3lzdGVtLXdpZGUgUEFT SUQgc3BhY2UKKiBNdWx0aXBsZSBjb25zdW1lcnMsIGVhY2ggYXNzb2NpYXRpbmcgdGhlaXIgb3du IHN0cnVjdHVyZSB0byBQQVNJRHMuCiAgRWFjaCBjb25zdW1lciBnZXRzIGEgdG9rZW4uCiogRGV2 aWNlIGRyaXZlcnMgbWlnaHQgd2FudCB0byB1c2UgYm90aCBTVkEgYW5kIHByaXZhdGUgUEFTSURz IGZvciBhCiAgZGV2aWNlIGF0IHRoZSBzYW1lIHRpbWUuCiogSW4gbXkgb3BpbmlvbiAicGFzaWQi IGlzbid0IHRoZSByaWdodCBuYW1lLCAiaW9hc2lkIiB3b3VsZCBiZSBiZXR0ZXIKICBidXQgdGhh dCdzIG5vdCBpbXBvcnRhbnQuCgp0eXBlZGVmIHVuc2lnbmVkIGludCBwYXNpZF90OwoKLyogUmV0 dXJucyBjb25zdW1lciB0b2tlbiAqLwp2b2lkICpwYXNpZF9nZXRfY29uc3VtZXIoKTsKdm9pZCBw YXNpZF9wdXRfY29uc3VtZXIodm9pZCAqY29uc3VtZXIpOwoKLyogUmV0dXJucyBwYXNpZCBvciBp bnZhbGlkIChwYXNpZF90KSgtMSkgKi8KcGFzaWRfdCBwYXNpZF9hbGxvYyh2b2lkICpjb25zdW1l ciwgcGFzaWRfdCBtaW4sIHBhc2lkX3QgbWF4LAogICAgICAgICAgICAgICAgICAgIHZvaWQgKnBy aXZhdGUpOwp2b2lkIHBhc2lkX3JlbW92ZShwYXNpZF90IHBhc2lkKTsKCi8qIEl0ZXJhdGUgb3Zl ciBQQVNJRHMgZm9yIHRoaXMgY29uc3VtZXIuIEZ1bmMgcmV0dXJucyBub24temVybyB0byBzdG9w Cml0ZXJhdGluZyAqLwppbnQgcGFzaWRfZm9yX2VhY2godm9pZCAqY29uc3VtZXIsIHZvaWQgKml0 ZXJfZGF0YSwKCQkgICBpbnQgKCpmdW5jKSh2b2lkICppdGVyX2RhdGEsIHBhc2lkX3QgcGFzaWQs CgkJCSAgICAgICB2b2lkICpwcml2YXRlKSk7Ci8qIFJldHVybnMgcHJpdiBkYXRhIG9yIE5VTEwg Ki8Kdm9pZCAqcGFzaWRfZmluZCh2b2lkICpjb25zdW1lciwgcGFzaWRfdCBwYXNpZCk7CgpUaGFu a3MsCkplYW4KCj4gQW5kIHRoaXMgY29kZSBtaWdodCBydW4gaW50byBwcm9ibGVtIGlmIHRoZSBw YXNpZCBpcyBhbGxvY2F0ZWQgZm9yCj4gdXNhZ2VzIG90aGVyIHRoYW4gU1ZBLgo+IAo+IEJlc3Qg cmVnYXJkcywKPiBMdSBCYW9sdQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KaW9tbXUgbWFpbGluZyBsaXN0CmlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRp b24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lvbW11