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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 DAFB9C433B4 for ; Wed, 7 Apr 2021 02:06:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BB50C613B7 for ; Wed, 7 Apr 2021 02:06:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343750AbhDGCHE (ORCPT ); Tue, 6 Apr 2021 22:07:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:29331 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241715AbhDGCHD (ORCPT ); Tue, 6 Apr 2021 22:07:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617761214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eTZmJYI/IOE6eZrevZtsuKN2bM+b1mDhI0WPZSfz0LQ=; b=G3TZXjtlMrQ82v2jOE3+uJ4bYtpNVTECX0od4JC59dB8MJNy9wmOHeqZgyM6VNQpZzQN5g vd/A5ApgpUmc4wnoMHJfWU4afwjWOIzIDzHX474Mjo85xkk53yB32Q+teTB3UP2iq+rwrp cL/Tm7f3qjZ5JngN6gNFkJU1bRpCM50= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-369-QSgasZZhPcmqG8yYOFuXrA-1; Tue, 06 Apr 2021 22:06:50 -0400 X-MC-Unique: QSgasZZhPcmqG8yYOFuXrA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AB315107ACCD; Wed, 7 Apr 2021 02:06:47 +0000 (UTC) Received: from wangxiaodeMacBook-Air.local (ovpn-13-182.pek2.redhat.com [10.72.13.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9838910023B5; Wed, 7 Apr 2021 02:06:33 +0000 (UTC) Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs To: Jason Gunthorpe Cc: "Tian, Kevin" , Jacob Pan , Jean-Philippe Brucker , LKML , Joerg Roedel , Lu Baolu , David Woodhouse , "iommu@lists.linux-foundation.org" , "cgroups@vger.kernel.org" , Tejun Heo , Li Zefan , Johannes Weiner , Jean-Philippe Brucker , Alex Williamson , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" References: <20210319135432.GT2356281@nvidia.com> <20210319112221.5123b984@jacob-builder> <20210322120300.GU2356281@nvidia.com> <20210324120528.24d82dbd@jacob-builder> <20210329163147.GG2356281@nvidia.com> <20210330132830.GO2356281@nvidia.com> <20210405234230.GF7405@nvidia.com> <20210406124251.GO7405@nvidia.com> From: Jason Wang Message-ID: Date: Wed, 7 Apr 2021 10:06:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210406124251.GO7405@nvidia.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ÔÚ 2021/4/6 ÏÂÎç8:42, Jason Gunthorpe дµÀ: > On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote: > >>> VFIO and VDPA has no buisness having map/unmap interfaces once we have >>> /dev/ioasid. That all belongs in the iosaid side. >>> >>> I know they have those interfaces today, but that doesn't mean we have >>> to keep using them for PASID use cases, they should be replaced with a >>> 'do dma from this pasid on /dev/ioasid' interface certainly not a >>> 'here is a pasid from /dev/ioasid, go ahead and configure it youself' >>> interface >> >> So it looks like the PASID was bound to SVA in this design. I think it's not >> necessairly the case: > No, I wish people would stop talking about SVA. > > SVA and vSVA are a very special narrow configuration of a PASID. There > are lots of other PASID configurations! That is the whole point, a > PASID is complicated, there are many configuration scenarios, they > need to be in one place with a very clearly defined uAPI Right, that's my understanding as well. > >> 1) PASID can be implemented without SVA, in this case a map/unmap interface >> is still required > Any interface to manipulate a PASID should be under /dev/ioasid. We do > not want to duplicate this into every subsystem. Yes. > >> 2) For the case that hypervisor want to do some mediation in the middle for >> a virtqueue. e.g in the case of control vq that is implemented in the >> VF/ADI/SF itself, the hardware virtqueue needs to be controlled by Qemu, >> Though binding qemu's page table to cvq can work but it looks like a >> overkill, a small dedicated buffers that is mapped for this PASID seems more >> suitalbe. > /dev/ioasid should allow userspace to setup any PASID configuration it > wants. There are many choices. That is the whole point, instead of > copying&pasting all the PASID configuration option into every > subsystem we have on place to configure it. > > If you want a PASID (or generic ioasid) that has the guest physical > map, which is probably all that VDPA would ever want, then /dev/ioasid > should be able to prepare that. > > If you just want to map a few buffers into a PASID then it should be > able to do that too. > >> So do you mean the device should not expose the PASID confiugration API to >> guest? I think it could happen if we assign the whole device and let guest >> to configure it for nested VMs. > This always needs co-operating with the vIOMMU driver. We can't have > nested PASID use without both parts working together. > > The vIOMMU driver configures the PASID and assigns the mappings > (however complicated that turns out to be) > > The VDPA/mdev driver authorizes the HW to use the ioasid mapping, eg > by authorizing a queue to issue PCIe TLPs with a specific PASID. > > The authorization is triggered by the guest telling the vIOMMU to > allow a vRID to talk to a PASID, which qemu would have to translate to > telling something like the VDPA driver under the vRID that it can use > a PASID from /dev/ioasid > > For security a VDPA/mdev device MUST NOT issue PASIDs that the vIOMMU > has not authorized its vRID to use. Otherwise the security model of > something like VFIO in the guest becomes completely broken. Yes, that's how it should work. Thanks > > Jason > 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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 977BBC433B4 for ; Wed, 7 Apr 2021 02:07:00 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 33CEC611C1 for ; Wed, 7 Apr 2021 02:07:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33CEC611C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id E901E405A6; Wed, 7 Apr 2021 02:06:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6ZwiZUwWZcz; Wed, 7 Apr 2021 02:06:59 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTP id C4F464017B; Wed, 7 Apr 2021 02:06:58 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9E4F8C000B; Wed, 7 Apr 2021 02:06:58 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7A264C000A for ; Wed, 7 Apr 2021 02:06:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 526A540338 for ; Wed, 7 Apr 2021 02:06:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88fs_8A-SStu for ; Wed, 7 Apr 2021 02:06:55 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by smtp4.osuosl.org (Postfix) with ESMTPS id 901BD40332 for ; Wed, 7 Apr 2021 02:06:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617761214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eTZmJYI/IOE6eZrevZtsuKN2bM+b1mDhI0WPZSfz0LQ=; b=G3TZXjtlMrQ82v2jOE3+uJ4bYtpNVTECX0od4JC59dB8MJNy9wmOHeqZgyM6VNQpZzQN5g vd/A5ApgpUmc4wnoMHJfWU4afwjWOIzIDzHX474Mjo85xkk53yB32Q+teTB3UP2iq+rwrp cL/Tm7f3qjZ5JngN6gNFkJU1bRpCM50= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-369-QSgasZZhPcmqG8yYOFuXrA-1; Tue, 06 Apr 2021 22:06:50 -0400 X-MC-Unique: QSgasZZhPcmqG8yYOFuXrA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AB315107ACCD; Wed, 7 Apr 2021 02:06:47 +0000 (UTC) Received: from wangxiaodeMacBook-Air.local (ovpn-13-182.pek2.redhat.com [10.72.13.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9838910023B5; Wed, 7 Apr 2021 02:06:33 +0000 (UTC) Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs To: Jason Gunthorpe References: <20210319135432.GT2356281@nvidia.com> <20210319112221.5123b984@jacob-builder> <20210322120300.GU2356281@nvidia.com> <20210324120528.24d82dbd@jacob-builder> <20210329163147.GG2356281@nvidia.com> <20210330132830.GO2356281@nvidia.com> <20210405234230.GF7405@nvidia.com> <20210406124251.GO7405@nvidia.com> From: Jason Wang Message-ID: Date: Wed, 7 Apr 2021 10:06:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210406124251.GO7405@nvidia.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Cc: Jean-Philippe Brucker , "Tian, Kevin" , Alex Williamson , "Raj, Ashok" , Jonathan Corbet , Jean-Philippe Brucker , LKML , "Jiang, Dave" , "iommu@lists.linux-foundation.org" , Li Zefan , Johannes Weiner , Tejun Heo , "cgroups@vger.kernel.org" , "Wu, Hao" , David Woodhouse X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gbk"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" CtTaIDIwMjEvNC82IM/Czuc4OjQyLCBKYXNvbiBHdW50aG9ycGUg0LS1wDoKPiBPbiBUdWUsIEFw ciAwNiwgMjAyMSBhdCAwOTozNToxN0FNICswODAwLCBKYXNvbiBXYW5nIHdyb3RlOgo+Cj4+PiBW RklPIGFuZCBWRFBBIGhhcyBubyBidWlzbmVzcyBoYXZpbmcgbWFwL3VubWFwIGludGVyZmFjZXMg b25jZSB3ZSBoYXZlCj4+PiAvZGV2L2lvYXNpZC4gVGhhdCBhbGwgYmVsb25ncyBpbiB0aGUgaW9z YWlkIHNpZGUuCj4+Pgo+Pj4gSSBrbm93IHRoZXkgaGF2ZSB0aG9zZSBpbnRlcmZhY2VzIHRvZGF5 LCBidXQgdGhhdCBkb2Vzbid0IG1lYW4gd2UgaGF2ZQo+Pj4gdG8ga2VlcCB1c2luZyB0aGVtIGZv ciBQQVNJRCB1c2UgY2FzZXMsIHRoZXkgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggYQo+Pj4gJ2Rv IGRtYSBmcm9tIHRoaXMgcGFzaWQgb24gL2Rldi9pb2FzaWQnIGludGVyZmFjZSBjZXJ0YWlubHkg bm90IGEKPj4+ICdoZXJlIGlzIGEgcGFzaWQgZnJvbSAvZGV2L2lvYXNpZCwgZ28gYWhlYWQgYW5k IGNvbmZpZ3VyZSBpdCB5b3VzZWxmJwo+Pj4gaW50ZXJmYWNlCj4+ICAgCj4+IFNvIGl0IGxvb2tz IGxpa2UgdGhlIFBBU0lEIHdhcyBib3VuZCB0byBTVkEgaW4gdGhpcyBkZXNpZ24uIEkgdGhpbmsg aXQncyBub3QKPj4gbmVjZXNzYWlybHkgdGhlIGNhc2U6Cj4gTm8sIEkgd2lzaCBwZW9wbGUgd291 bGQgc3RvcCB0YWxraW5nIGFib3V0IFNWQS4KPgo+IFNWQSBhbmQgdlNWQSBhcmUgYSB2ZXJ5IHNw ZWNpYWwgbmFycm93IGNvbmZpZ3VyYXRpb24gb2YgYSBQQVNJRC4gVGhlcmUKPiBhcmUgbG90cyBv ZiBvdGhlciBQQVNJRCBjb25maWd1cmF0aW9ucyEgVGhhdCBpcyB0aGUgd2hvbGUgcG9pbnQsIGEK PiBQQVNJRCBpcyBjb21wbGljYXRlZCwgdGhlcmUgYXJlIG1hbnkgY29uZmlndXJhdGlvbiBzY2Vu YXJpb3MsIHRoZXkKPiBuZWVkIHRvIGJlIGluIG9uZSBwbGFjZSB3aXRoIGEgdmVyeSBjbGVhcmx5 IGRlZmluZWQgdUFQSQoKClJpZ2h0LCB0aGF0J3MgbXkgdW5kZXJzdGFuZGluZyBhcyB3ZWxsLgoK Cj4KPj4gMSkgUEFTSUQgY2FuIGJlIGltcGxlbWVudGVkIHdpdGhvdXQgU1ZBLCBpbiB0aGlzIGNh c2UgYSBtYXAvdW5tYXAgaW50ZXJmYWNlCj4+IGlzIHN0aWxsIHJlcXVpcmVkCj4gQW55IGludGVy ZmFjZSB0byBtYW5pcHVsYXRlIGEgUEFTSUQgc2hvdWxkIGJlIHVuZGVyIC9kZXYvaW9hc2lkLiBX ZSBkbwo+IG5vdCB3YW50IHRvIGR1cGxpY2F0ZSB0aGlzIGludG8gZXZlcnkgc3Vic3lzdGVtLgoK Clllcy4KCgo+Cj4+IDIpIEZvciB0aGUgY2FzZSB0aGF0IGh5cGVydmlzb3Igd2FudCB0byBkbyBz b21lIG1lZGlhdGlvbiBpbiB0aGUgbWlkZGxlIGZvcgo+PiBhIHZpcnRxdWV1ZS4gZS5nIGluIHRo ZSBjYXNlIG9mIGNvbnRyb2wgdnEgdGhhdCBpcyBpbXBsZW1lbnRlZCBpbiB0aGUKPj4gVkYvQURJ L1NGIGl0c2VsZiwgdGhlIGhhcmR3YXJlIHZpcnRxdWV1ZSBuZWVkcyB0byBiZSBjb250cm9sbGVk IGJ5IFFlbXUsCj4+IFRob3VnaCBiaW5kaW5nIHFlbXUncyBwYWdlIHRhYmxlIHRvIGN2cSBjYW4g d29yayBidXQgaXQgbG9va3MgbGlrZSBhCj4+IG92ZXJraWxsLCBhIHNtYWxsIGRlZGljYXRlZCBi dWZmZXJzIHRoYXQgaXMgbWFwcGVkIGZvciB0aGlzIFBBU0lEIHNlZW1zIG1vcmUKPj4gc3VpdGFs YmUuCj4gL2Rldi9pb2FzaWQgc2hvdWxkIGFsbG93IHVzZXJzcGFjZSB0byBzZXR1cCBhbnkgUEFT SUQgY29uZmlndXJhdGlvbiBpdAo+IHdhbnRzLiBUaGVyZSBhcmUgbWFueSBjaG9pY2VzLiBUaGF0 IGlzIHRoZSB3aG9sZSBwb2ludCwgaW5zdGVhZCBvZgo+IGNvcHlpbmcmcGFzdGluZyBhbGwgdGhl IFBBU0lEIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGludG8gZXZlcnkKPiBzdWJzeXN0ZW0gd2UgaGF2 ZSBvbiBwbGFjZSB0byBjb25maWd1cmUgaXQuCj4KPiBJZiB5b3Ugd2FudCBhIFBBU0lEIChvciBn ZW5lcmljIGlvYXNpZCkgdGhhdCBoYXMgdGhlIGd1ZXN0IHBoeXNpY2FsCj4gbWFwLCB3aGljaCBp cyBwcm9iYWJseSBhbGwgdGhhdCBWRFBBIHdvdWxkIGV2ZXIgd2FudCwgdGhlbiAvZGV2L2lvYXNp ZAo+IHNob3VsZCBiZSBhYmxlIHRvIHByZXBhcmUgdGhhdC4KPgo+IElmIHlvdSBqdXN0IHdhbnQg dG8gbWFwIGEgZmV3IGJ1ZmZlcnMgaW50byBhIFBBU0lEIHRoZW4gaXQgc2hvdWxkIGJlCj4gYWJs ZSB0byBkbyB0aGF0IHRvby4KPgo+PiBTbyBkbyB5b3UgbWVhbiB0aGUgZGV2aWNlIHNob3VsZCBu b3QgZXhwb3NlIHRoZSBQQVNJRCBjb25maXVncmF0aW9uIEFQSSB0bwo+PiBndWVzdD8gSSB0aGlu ayBpdCBjb3VsZCBoYXBwZW4gaWYgd2UgYXNzaWduIHRoZSB3aG9sZSBkZXZpY2UgYW5kIGxldCBn dWVzdAo+PiB0byBjb25maWd1cmUgaXQgZm9yIG5lc3RlZCBWTXMuCj4gVGhpcyBhbHdheXMgbmVl ZHMgY28tb3BlcmF0aW5nIHdpdGggdGhlIHZJT01NVSBkcml2ZXIuIFdlIGNhbid0IGhhdmUKPiBu ZXN0ZWQgUEFTSUQgdXNlIHdpdGhvdXQgYm90aCBwYXJ0cyB3b3JraW5nIHRvZ2V0aGVyLgo+Cj4g VGhlIHZJT01NVSBkcml2ZXIgY29uZmlndXJlcyB0aGUgUEFTSUQgYW5kIGFzc2lnbnMgdGhlIG1h cHBpbmdzCj4gKGhvd2V2ZXIgY29tcGxpY2F0ZWQgdGhhdCB0dXJucyBvdXQgdG8gYmUpCj4KPiBU aGUgVkRQQS9tZGV2IGRyaXZlciBhdXRob3JpemVzIHRoZSBIVyB0byB1c2UgdGhlIGlvYXNpZCBt YXBwaW5nLCBlZwo+IGJ5IGF1dGhvcml6aW5nIGEgcXVldWUgdG8gaXNzdWUgUENJZSBUTFBzIHdp dGggYSBzcGVjaWZpYyBQQVNJRC4KPgo+IFRoZSBhdXRob3JpemF0aW9uIGlzIHRyaWdnZXJlZCBi eSB0aGUgZ3Vlc3QgdGVsbGluZyB0aGUgdklPTU1VIHRvCj4gYWxsb3cgYSB2UklEIHRvIHRhbGsg dG8gYSBQQVNJRCwgd2hpY2ggcWVtdSB3b3VsZCBoYXZlIHRvIHRyYW5zbGF0ZSB0bwo+IHRlbGxp bmcgc29tZXRoaW5nIGxpa2UgdGhlIFZEUEEgZHJpdmVyIHVuZGVyIHRoZSB2UklEIHRoYXQgaXQg Y2FuIHVzZQo+IGEgUEFTSUQgZnJvbSAvZGV2L2lvYXNpZAo+Cj4gRm9yIHNlY3VyaXR5IGEgVkRQ QS9tZGV2IGRldmljZSBNVVNUIE5PVCBpc3N1ZSBQQVNJRHMgdGhhdCB0aGUgdklPTU1VCj4gaGFz IG5vdCBhdXRob3JpemVkIGl0cyB2UklEIHRvIHVzZS4gT3RoZXJ3aXNlIHRoZSBzZWN1cml0eSBt b2RlbCBvZgo+IHNvbWV0aGluZyBsaWtlIFZGSU8gaW4gdGhlIGd1ZXN0IGJlY29tZXMgY29tcGxl dGVseSBicm9rZW4uCgoKWWVzLCB0aGF0J3MgaG93IGl0IHNob3VsZCB3b3JrLgoKVGhhbmtzCgoK Pgo+IEphc29uCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmlvbW11IG1haWxpbmcgbGlzdAppb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpo dHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb21tdQ== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs Date: Wed, 7 Apr 2021 10:06:30 +0800 Message-ID: References: <20210319135432.GT2356281@nvidia.com> <20210319112221.5123b984@jacob-builder> <20210322120300.GU2356281@nvidia.com> <20210324120528.24d82dbd@jacob-builder> <20210329163147.GG2356281@nvidia.com> <20210330132830.GO2356281@nvidia.com> <20210405234230.GF7405@nvidia.com> <20210406124251.GO7405@nvidia.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617761214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eTZmJYI/IOE6eZrevZtsuKN2bM+b1mDhI0WPZSfz0LQ=; b=G3TZXjtlMrQ82v2jOE3+uJ4bYtpNVTECX0od4JC59dB8MJNy9wmOHeqZgyM6VNQpZzQN5g vd/A5ApgpUmc4wnoMHJfWU4afwjWOIzIDzHX474Mjo85xkk53yB32Q+teTB3UP2iq+rwrp cL/Tm7f3qjZ5JngN6gNFkJU1bRpCM50= In-Reply-To: <20210406124251.GO7405-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> List-ID: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: Jason Gunthorpe Cc: "Tian, Kevin" , Jacob Pan , Jean-Philippe Brucker , LKML , Joerg Roedel , Lu Baolu , David Woodhouse , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Tejun Heo , Li Zefan , Johannes Weiner , Jean-Philippe Brucker , Alex Williamson , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" =D4=DA 2021/4/6 =CF=C2=CE=E78:42, Jason Gunthorpe =D0=B4=B5=C0: > On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote: > >>> VFIO and VDPA has no buisness having map/unmap interfaces once we have >>> /dev/ioasid. That all belongs in the iosaid side. >>> >>> I know they have those interfaces today, but that doesn't mean we have >>> to keep using them for PASID use cases, they should be replaced with a >>> 'do dma from this pasid on /dev/ioasid' interface certainly not a >>> 'here is a pasid from /dev/ioasid, go ahead and configure it youself' >>> interface >> =20 >> So it looks like the PASID was bound to SVA in this design. I think it's= not >> necessairly the case: > No, I wish people would stop talking about SVA. > > SVA and vSVA are a very special narrow configuration of a PASID. There > are lots of other PASID configurations! That is the whole point, a > PASID is complicated, there are many configuration scenarios, they > need to be in one place with a very clearly defined uAPI Right, that's my understanding as well. > >> 1) PASID can be implemented without SVA, in this case a map/unmap interf= ace >> is still required > Any interface to manipulate a PASID should be under /dev/ioasid. We do > not want to duplicate this into every subsystem. Yes. > >> 2) For the case that hypervisor want to do some mediation in the middle = for >> a virtqueue. e.g in the case of control vq that is implemented in the >> VF/ADI/SF itself, the hardware virtqueue needs to be controlled by Qemu, >> Though binding qemu's page table to cvq can work but it looks like a >> overkill, a small dedicated buffers that is mapped for this PASID seems = more >> suitalbe. > /dev/ioasid should allow userspace to setup any PASID configuration it > wants. There are many choices. That is the whole point, instead of > copying&pasting all the PASID configuration option into every > subsystem we have on place to configure it. > > If you want a PASID (or generic ioasid) that has the guest physical > map, which is probably all that VDPA would ever want, then /dev/ioasid > should be able to prepare that. > > If you just want to map a few buffers into a PASID then it should be > able to do that too. > >> So do you mean the device should not expose the PASID confiugration API = to >> guest? I think it could happen if we assign the whole device and let gue= st >> to configure it for nested VMs. > This always needs co-operating with the vIOMMU driver. We can't have > nested PASID use without both parts working together. > > The vIOMMU driver configures the PASID and assigns the mappings > (however complicated that turns out to be) > > The VDPA/mdev driver authorizes the HW to use the ioasid mapping, eg > by authorizing a queue to issue PCIe TLPs with a specific PASID. > > The authorization is triggered by the guest telling the vIOMMU to > allow a vRID to talk to a PASID, which qemu would have to translate to > telling something like the VDPA driver under the vRID that it can use > a PASID from /dev/ioasid > > For security a VDPA/mdev device MUST NOT issue PASIDs that the vIOMMU > has not authorized its vRID to use. Otherwise the security model of > something like VFIO in the guest becomes completely broken. Yes, that's how it should work. Thanks > > Jason >