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>
CC:     Lu Baolu <baolu.lu@linux.intel.com>,
        "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>,
        "jean-philippe@linaro.org" <jean-philippe@linaro.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>,
        "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: RE: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma
 interfaces
Thread-Topic: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma
 interfaces
Thread-Index: AQHXrSF9WDj+Z+DU+UqMJ7tQK2EdmauuvK2AgACKnbCAALw6gIAHYVYAgACkNwCAAQ1OQIAAT36AgAAbKoCAAAj5AIAAq5rggADTsACAGGANEA==
Date:   Fri, 15 Oct 2021 01:29:16 +0000
Message-ID: <BN9PR11MB5433C616093C8DDA5A859C2F8CB99@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <20210921170943.GS327412@nvidia.com>
 <BN9PR11MB5433DA330D4583387B59AA7F8CA29@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210922123931.GI327412@nvidia.com>
 <BN9PR11MB5433CE19425E85E7F52093278CA79@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210927150928.GA1517957@nvidia.com>
 <BN9PR11MB54337B7F65B98C2335B806938CA89@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210928115751.GK964074@nvidia.com>
 <9a314095-3db9-30fc-2ed9-4e46d385036d@linux.intel.com>
 <20210928140712.GL964074@nvidia.com>
 <BN9PR11MB5433B8CB2F1EA1A2D06586588CA99@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210929125902.GU964074@nvidia.com>
In-Reply-To: <20210929125902.GU964074@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.6.200.16
dlp-product: dlpe-windows
dlp-reaction: no-action
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NC2YkdSmqqw7/PmdKQPi/0bP0tUnc6JxjvhoVoOMp+Tw40/S/lp6KgbFCiNb?=
 =?us-ascii?Q?bPUaa/k9d1JyOvBUj6s8F33moi6otuFQmrKQAJkWfrhn2k4OpOf+cBQQlcdn?=
 =?us-ascii?Q?wDXzJmNOcXk98soa71wA0R6qdG6PGxyfqYVEMFGWrTu6wCa58Gueu39FrsRT?=
 =?us-ascii?Q?FRTo3+lLfbumpdcT4/2T4YolrXvMkfkdKDGSY+uLVg50WuMQkC8eXnFaMqEs?=
 =?us-ascii?Q?esGPy0ka5aEFuBiUqlrd/jPKtVIeC45f/+D87Nr718GnwyLg5pwLuR+kknAX?=
 =?us-ascii?Q?WmYTzYeuAYIX3wkXapAT1g3JNk4RsA6jGdedDLH48XOJM03j7Wj4v8LL66TO?=
 =?us-ascii?Q?hRV4pzrueUGj09f8QureeSXR/sYrHFgSK1FnvotAxXC/u64S4Q1QBBj6t9vQ?=
 =?us-ascii?Q?kdDsryW8NOwoOmD69USeN28bjXwq+rVuARNpcYN1AMLuAoIgBSZf6ks36Wrv?=
 =?us-ascii?Q?06f0mrkqSSMmwNm81jVqd1nGuLailEVRFNlvdrUTF1Yq/yVf6Om7P4hpX7Us?=
 =?us-ascii?Q?iN0V7WMZlR9TqHNPfwwBX2gNylb/Dbl1iuF51No+tR+L5si1aKfjxk6pQBIB?=
 =?us-ascii?Q?nkEE3iwdLJ81XtRCWK5wZiDV2yGeIXwbGp/sosG7QxCZcpaU+ifMdLSptqY0?=
 =?us-ascii?Q?KM0yVWkEG7iGZiBrUfh598j5pGe5fFOw2TGc3DLDrWnKZtkhNOUtl/CgAVTX?=
 =?us-ascii?Q?E6ol6BH8mJRrhjbtipGnqpx9sKzOLlPIABPRBiy7PCjzmRMVjN16DyRhdJ0w?=
 =?us-ascii?Q?373h8B1pMC3VMNDjT01hoZQvUfKC6jSBwW8jAZB5rKIqAp8VLLmbFcNMX7K8?=
 =?us-ascii?Q?vddEA++FUznSn9ZBPYANTpu59eHUjHIYS79XzkyO47RUjrbfsReGVoFg84vY?=
 =?us-ascii?Q?EaRc47unFV/271BTzPIgbnT1JeCCjC22IjqjGbTdIfdVgrpVZqzzVHcgadaU?=
 =?us-ascii?Q?nF8233zSuNcm+Y96pV2c9/lDEckl/gmSrndWBWVbHdngtHgm4Xzj6vFXROlV?=
 =?us-ascii?Q?vDmnx4pmfpoiwXtSkmF9R1PnGuiqZuyaiywVkMbKY258pcda39UGfVzjLMU9?=
 =?us-ascii?Q?3+oW0+gQ8fx/N8K2Xs3qiaUs/a77xue4tDeKa9Ec9NwLWfOvNrsA/8Iw0WpV?=
 =?us-ascii?Q?HztK4+V5GNNOOBYbXPr9Nxc3O0WJ65bYFCRWC1Kmp22UBcsQnnU70dEtDpjA?=
 =?us-ascii?Q?JiL+PIjKLBRmEB8WZ/XJICcJBWY4lC1cToAfhaVlOGj0WAMzuTEWg08CPNUz?=
 =?us-ascii?Q?S/PvCTwS78nr0hzAJmlnSDzLl/qSyGna0M4JrlmXzon6fLgc2kGrjyApNGkS?=
 =?us-ascii?Q?0Dloodc50f7CM1JL1JlL8bao?=
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: 0ac29195-0dbf-4952-3c38-08d98f7b3449
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 01:29:16.8320
 (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: 2Al97JljauGF4GJSuqQWnX2hTZBY6NxZJjbrlf/8uzhgEfghVU4lbTU9JqIaKUoXsTBH+krIL++uAnQTLtEU/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2850
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi, Jason,

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, September 29, 2021 8:59 PM
>=20
> On Wed, Sep 29, 2021 at 12:38:35AM +0000, Tian, Kevin wrote:
>=20
> > /* If set the driver must call iommu_XX as the first action in probe() =
or
> >   * before it attempts to do DMA
> >   */
> >  bool suppress_dma_owner:1;
>=20
> It is not "attempts to do DMA" but more "operates the physical device
> in any away"
>=20
> Not having ownership means another entity could be using user space
> DMA to manipulate the device state and attack the integrity of the
> kernel's programming of the device.
>=20

Does suppress_kernel_dma sounds better than suppress_dma_owner?
We found the latter causing some confusion when doing internal
code review. Somehow this flag represents "don't claim the kernel dma
ownership during driver binding". suppress_dma_owner sounds the
entire ownership is disabled...

Another thing is about DMA_OWNER_SHARED, which is set to indicate=20
no dma at all. Thinking more we feel that this flag is meaningless. Its
sole purpose is to show compatibility to any USER/KERNEL ownership,=20
and essentially the same semantics as a device which is not bound to
any driver. So we plan to remove it then pci-stub just needs one line=20
change to set the suppress flag. But want to check with you first in case
any oversight.

Thanks
Kevin