Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>,
        David Gibson <david@gibson.dropbear.id.au>
CC:     "Alex Williamson (alex.williamson@redhat.com)" 
        <alex.williamson@redhat.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Jason Wang <jasowang@redhat.com>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Shenming Lu <lushenming@huawei.com>,
        Joerg Roedel <joro@8bytes.org>,
        Eric Auger <eric.auger@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        Jacob Pan <jacob.jun.pan@linux.intel.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        "Robin Murphy" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "David Woodhouse" <dwmw2@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "Lu Baolu" <baolu.lu@linux.intel.com>
Subject: RE: [RFC v2] /dev/iommu uAPI proposal
Thread-Topic: [RFC v2] /dev/iommu uAPI proposal
Thread-Index: Add0lrMH87IsTsl5Rp6WN1oQU6kGMQNQxoYAAN4kDIAAfDtbgA==
Date:   Mon, 2 Aug 2021 02:49:44 +0000
Message-ID: <BN9PR11MB5433C34222B3E727B3D0E5638CEF9@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <BN9PR11MB5433B1E4AE5B0480369F97178C189@BN9PR11MB5433.namprd11.prod.outlook.com>
 <YP4/KJoYfbaf5U94@yekko> <20210730145123.GW1721383@nvidia.com>
In-Reply-To: <20210730145123.GW1721383@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
dlp-reaction: no-action
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?3n3cX4nCDlpCt1I+3ZaAwGJqJkJ3Yc/AYD+Lm+/KlSm51elMXQYXc2MfJT6r?=
 =?us-ascii?Q?GnKZlRfFwlBMDLEcV4SDMax39eZNYHFZm+IGH9FrBc/OzPabFuLtdBzT1maX?=
 =?us-ascii?Q?iFtUpnnzHK+VLUMkfrw4BodEJRDr2AZNTVJaqYT21jihWTkFHQAx/cOcySeV?=
 =?us-ascii?Q?9tey+G3nNoBJGHWbfnZbUSX6moCCrsvvmgaMzPUTucFuV3jB3yS2rnJ/ywQl?=
 =?us-ascii?Q?r+fMwwp+yqdoMUN7sbs48TmZlTc7TTQBItzf/N+6HSjhgwYCtMiTOuT17Kmz?=
 =?us-ascii?Q?ItEo/Hba3Ze3Wo+2CxQQYR5QaD1FZPLH1UKSUf/jqSwwYZp0W5jy2tlsJf/w?=
 =?us-ascii?Q?yqmdWAOWJ1LkXSv85aADX2OC6rKkEitX7cI/wxX+ovamhq2HAvMtjoA18hKI?=
 =?us-ascii?Q?aviJtQ/sPNxe8UGhRK8KEZRBOX1Bx8wO8FMvYXKMgs8vpp/V7daPLoBg+FB7?=
 =?us-ascii?Q?+llsLiMReKo6/JP0uauJJzvYUbyodv7KzlQozMdsF9CftMwJNe40lxz2ORBf?=
 =?us-ascii?Q?60QawwfhNiQCwQ6LFCbYn5i5TpZX0zv1n1Nv5vzygnaSULs31s2936/yGieQ?=
 =?us-ascii?Q?tlsAmOKtanNWhPCMqcZJlGajLByQ3x+lorOy8U7oazSSNt++TqgFyLoEfra8?=
 =?us-ascii?Q?Me1CQwmViGOFKjhZSBvTf/t48d3jge64003nnzyLovNkqWvJJ5IyoYTJLO8X?=
 =?us-ascii?Q?bCo5Wdd9NLHSyRbWwWiAdI9OO2vxOss52XMQ1iLVxGN8/J5DjUs6L5pbr1qn?=
 =?us-ascii?Q?xIM64IXKUUxwnWFBXmhOl3H9J63r2nzxESKcHWRTcvxa+awoJ/6dfZIkUFTV?=
 =?us-ascii?Q?L2yck5eI40eYmSF6hnfwMaUBUF1RtNhLkBiCtYhIt+Vc5MpbL2YpIlJF72CV?=
 =?us-ascii?Q?IaxQZRhSmJwKSQHrXn7fuMo3NeGgABNTAfB++iAAzfkEmzJRwZpd+TwCFzQJ?=
 =?us-ascii?Q?JWzD1HarQHxLXDPQWeLmGijcxY8pVCWXsOrUNX72WwXXVt6NEimNQYj33kST?=
 =?us-ascii?Q?uCPp1SD0BhovMbiyRaeO1WWhYs25O+G204cDeTcNRH6PIEUnLNeoqVqWpxWl?=
 =?us-ascii?Q?RzxSYxYQ0sYi1sk18GctCD3zws/sglTV3DLS07YmCxe/BQTQ0xwHPSTuUmU3?=
 =?us-ascii?Q?l0utZQqAAynBpmuz9+jyJb9tvVZGDNakaDylT4xkxlnxSfrxrCD3lR1TYmL8?=
 =?us-ascii?Q?sz5Pd5dgDNyY0CTWNDN/WM2iP5QiM52RAMyH6eOVl+AQO9ywtzV4ZXgeuB5s?=
 =?us-ascii?Q?NORGbuEsrGnpiOHhIGfhTZ8n5yXKTt74xusV8NA4PItlMQEwO+EL7OUC+GGd?=
 =?us-ascii?Q?QtpR1G6UMqG9BnCOEOwkZPme?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5433.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 65f6dafc-f0d6-4bde-b96a-08d955602f69
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2021 02:49:44.8403
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Q7E0Xf9LY2cW31wX+fYrbAP4xixD0BT5fF/ENp+7MrPGx0QZA+ayFxPnP86tZ0kTMzI5P4Xb9p8YcDMUp7PIXA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB2018
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, July 30, 2021 10:51 PM
>=20
> On Mon, Jul 26, 2021 at 02:50:48PM +1000, David Gibson wrote:
>=20
> > That said, I'm still finding the various ways a device can attach to
> > an ioasid pretty confusing.  Here are some thoughts on some extra
> > concepts that might make it easier to handle [note, I haven't thought
> > this all the way through so far, so there might be fatal problems with
> > this approach].
>=20
> I think you've summarized how I've been viewing this problem. All the
> concepts you pointed to should show through in the various APIs at the
> end, one way or another.

I still didn't get the value of making endpoint explicit in /dev/iommu uAPI=
.=20
From IOMMU p.o.v it only cares how to route incoming DMA traffic to a
specific I/O page table, according to RID or RID+PASID info carried in DMA=
=20
packets. This has been covered by this proposal. Which DMA endpoint in=20
the source device actually triggers the traffic is not a matter for /dev/io=
mmu...

>=20
> How much we need to expose to userspace, I don't know.
>=20
> Does userspace need to care how the system labels traffic between DMA
> endpoint and the IOASID? At some point maybe yes since stuff like
> PASID does leak out in various spots
>=20

Can you elaborate? IMO the user only cares about the label (device cookie=20
plus optional vPASID) which is generated by itself when doing the attaching
call, and expects this virtual label being used in various spots (invalidat=
ion,
page fault, etc.). How the system labels the traffic (the physical RID or R=
ID+
PASID) should be completely invisible to userspace.

Thanks
Kevin