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:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Jason Gunthorpe <jgg@nvidia.com>
CC:     David Gibson <david@gibson.dropbear.id.au>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "hch@lst.de" <hch@lst.de>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "lkml@metux.net" <lkml@metux.net>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
        "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: RE: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
Thread-Topic: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
Thread-Index: AQHXrSGPLoYXtOF3o0iA7Cse+/LM66uuxm8AgA72WACAAGbxgIAPTQiAgAAu7ICAAPgygIAAlZ0AgAF6T2A=
Date:   Wed, 13 Oct 2021 07:14:54 +0000
Message-ID: <BN9PR11MB5433C0D532DA55D4584216A08CB79@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <20210919063848.1476776-1-yi.l.liu@intel.com>
 <20210919063848.1476776-12-yi.l.liu@intel.com>
 <20210921174438.GW327412@nvidia.com> <YVanJqG2pt6g+ROL@yekko>
 <20211001122225.GK964074@nvidia.com> <YWPTWdHhoI4k0Ksc@yekko>
 <YWP6tblC2+/2RQtN@myrica> <20211011233817.GS2744544@nvidia.com>
 <YWVIagFiOtXTGMQ+@myrica>
In-Reply-To: <YWVIagFiOtXTGMQ+@myrica>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?whm1gUAE2WbytMwW/qR0lNMjxIiKb60GJULJaWoKKmvQT5EgMiHD5trQWqQm?=
 =?us-ascii?Q?lSPhrAUrtWuJIXDmEZvj2cNiV3Rndfjn97GK0AtoSGIzP5fCmzMUmeL6I9Do?=
 =?us-ascii?Q?LSIk9UIDg6lelceDYOER3qJxmK9woCJMrp0epScrGJfPMrX7oY7hr5RS12Dc?=
 =?us-ascii?Q?j5fjfPCJX0MpxDjYeGbACADaYbgyfN0M9XKGO+PpHdCD/xc3N5yn2SczSC50?=
 =?us-ascii?Q?57+OMSmHRW29YiKXGJXUrgnYlqmeG7Zw2fAHytXBLSW8pqMH19fFQvruRm5h?=
 =?us-ascii?Q?eiA5T8ceVyyofsYHgf9WtYK1CUxUkKZCyMU97S/M4eS+ko4mjE0vr7CUOkvB?=
 =?us-ascii?Q?avSbZyACcbA5iaXZrSv7LJZtitx1pVAk/rZZhO0R5HQzCiHOX0Ah8LZntTC0?=
 =?us-ascii?Q?gL2WhHs54nXG+sNk9qAOkwoqtpiY3fz7OwfM3z6PcTdt74MX6hDVbkBwSz8d?=
 =?us-ascii?Q?oDSleb0kPB8cSnIkSTFAWN8jUZ8x7Dp3IkgZbvb8t+JnS7fimrzx8S66YMS6?=
 =?us-ascii?Q?0COyZv80NQWrKGUJuTublGb8bkzia4lpfp5ylLYe232jEoOx4cUGnakYX/BR?=
 =?us-ascii?Q?66zs7wZB5gUAkG4/nWBEPT7gRjG0cb5ZRXDteXBw7X4buLUeTZc8sCF1RPxk?=
 =?us-ascii?Q?qQuLSQGa2Tsk3VsC0nttD+jg9L+AOqZxNOhKHHSJ5pGOm/dvfoFdYXr3rdZN?=
 =?us-ascii?Q?lm1WhkUFwEnfdOxoxNRGxTf+sNOeNTRPaHhUHyEZwBBPTgJ1XfSsz2XcAyM7?=
 =?us-ascii?Q?4UhO202j4W3Wi4nRJwr/pWajDt/kHXm4ZhUgoJQ0NyVyncrO2HhXxYucTbb8?=
 =?us-ascii?Q?dr6o9PYhv6hnSqX1LmLSpYQXN4Zk0DFn35pd0CizqfQFJsMDKXzEgExWIGtK?=
 =?us-ascii?Q?RXT1bLyr8P/Zs3LkdO7L12iCY+80sLoOtCEuVRj2EqHCExR6z3Dt3fl1cYJG?=
 =?us-ascii?Q?CWLbsEoRykiOQHSqQ4g3KP36h6XzeKt8GlfI+cxtDDNmfeyqsfHLF3Avvghz?=
 =?us-ascii?Q?bviiZcdS8T/HHtOc7klTv7emDnS7oSVUDEUXT1KZM0pi5MIP5g4OL2o+z0Vm?=
 =?us-ascii?Q?IsUf6IsG+2YlbWv9z26gUgMjtGV+R/rcRazfKIpu6RP6ZqvmhJrhEkEQ4sFu?=
 =?us-ascii?Q?g1leNTjmaHm6Pf/LEsIl/vugDY80lqpPEMq4TAYPuUcbwmUJZaCqqBIEyCKE?=
 =?us-ascii?Q?aRFMf96nddRCdrA6b7cyXX4qjkoGmm3fVFwe0akcWK+SUq2lJKov+Q/q+sx0?=
 =?us-ascii?Q?6JIwbVvi+g1mdZ6lWHecoj34/a7Xj9QKLONjKos1C7LRrb1ZpbMbETp3heUZ?=
 =?us-ascii?Q?nOmvR7MU5cSKHk/3oVxzAyp6?=
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: 6e8011f1-f3ba-4428-7982-08d98e1927f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 07:14:54.4744
 (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: Mhnui/T1d8E4rWegezub3UQQQVmc1/ElVYjIjXCZF4DJDFVmWIo0y0gFRm8Rxewgixf3bO1L9GcOvuSJF21/+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3842
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Sent: Tuesday, October 12, 2021 4:34 PM
>=20
> On Mon, Oct 11, 2021 at 08:38:17PM -0300, Jason Gunthorpe wrote:
> > On Mon, Oct 11, 2021 at 09:49:57AM +0100, Jean-Philippe Brucker wrote:
> >
> > > Seems like we don't need the negotiation part?  The host kernel
> > > communicates available IOVA ranges to userspace including holes (patc=
h
> > > 17), and userspace can check that the ranges it needs are within the =
IOVA
> > > space boundaries. That part is necessary for DPDK as well since it ne=
eds
> > > to know about holes in the IOVA space where DMA wouldn't work as
> expected
> > > (MSI doorbells for example).
> >
> > I haven't looked super closely at DPDK, but the other simple VFIO app
> > I am aware of struggled to properly implement this semantic (Indeed it
> > wasn't even clear to the author this was even needed).
> >
> > It requires interval tree logic inside the application which is not a
> > trivial algorithm to implement in C.
> >
> > I do wonder if the "simple" interface should have an option more like
> > the DMA API where userspace just asks to DMA map some user memory
> and
> > gets back the dma_addr_t to use. Kernel manages the allocation
> > space/etc.
>=20
> Agreed, it's tempting to use IOVA =3D VA but the two spaces aren't
> necessarily compatible. An extension that plugs into the IOVA allocator
> could be useful to userspace drivers.
>=20

Make sense. We can have a flag in IOMMUFD_MAP_DMA to tell whether
the user provides vaddr or expects the kernel to allocate and return.

Thanks
Kevin