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>,
        Joerg Roedel <joro@8bytes.org>,
        Christoph Hellwig <hch@infradead.org>,
        Ben Skeggs <bskeggs@redhat.com>,
        "Raj, Ashok" <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Alex Williamson <alex.williamson@redhat.com>,
        "Eric Auger" <eric.auger@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Pan, Jacob jun" <jacob.jun.pan@intel.com>,
        David Airlie <airlied@linux.ie>,
        "Daniel Vetter" <daniel@ffwll.ch>,
        Thierry Reding <thierry.reding@gmail.com>,
        Jonathan Hunter <jonathanh@nvidia.com>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 0/7] iommu cleanup and refactoring
Thread-Topic: [PATCH 0/7] iommu cleanup and refactoring
Thread-Index: AQHYEPHAKjrfWJEn8EK96HWI6wkQH6xx4JAggACRgQCAAH0HkA==
Date:   Tue, 25 Jan 2022 01:11:55 +0000
Message-ID: <BN9PR11MB527647F0336BBD8528E3413B8C5F9@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20220124071103.2097118-1-baolu.lu@linux.intel.com>
 <BN9PR11MB52767F46CC13601306001B9E8C5E9@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20220124174404.GG966497@nvidia.com>
In-Reply-To: <20220124174404.GG966497@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?oXWWEJfaiAsoVEK1Su2U8AVUpshcqKceQhDANTQ86rM9cQOH2hCUnEKXJSTy?=
 =?us-ascii?Q?itYtgllTg7ZOFlPvpP8vepzLefq3CCH/31pkKmC0VUYbcsiqUflWw5b/YY3W?=
 =?us-ascii?Q?OQAFT/u0bcTpGPWMZ/+50AtZsN0mk0MDeS7BaQYm3UC1hqeOVNfUJRO2UdDa?=
 =?us-ascii?Q?bdsmc1HAZJ6bkqHRQeENVTWwNi1rHSlwjrwjXicTlqGg36Hr6nHiZChRlM3k?=
 =?us-ascii?Q?V9skdKPcP1qrSzsBXLv7MiUu2eAWvIzD5gjQMeGMhXLaTuYuiYchFZzDIFBQ?=
 =?us-ascii?Q?EYtYRm9dGR9YFXqSc75uPoPQAIWVj7J2720uvWP+4uMY7Xf0TjMQO2cPiwGo?=
 =?us-ascii?Q?AEGk8aqGSrr5oZFspGdgiCNn9hQEaocXwjp+JS3nN57sdhBAYSJHeMxk2e9J?=
 =?us-ascii?Q?eUwYj23FM5yJ9HT+2fuMDz8Zkq0sYHaGCLKaXH/9ZK/MyaAmU6slwo9dZteI?=
 =?us-ascii?Q?DIPZnVpp6mLsyuNQ+uDqFaIWWCrNYzVVjcHOX8YtlmnVrWTyipTeJaTbPmOC?=
 =?us-ascii?Q?b/ivKta7/nJz/YrQvkvwiPyQqEvHXpXOoYngx5m4XN8a/l6chJVvuZn/7JLE?=
 =?us-ascii?Q?w8TR0kLEQH2bX52enCbSic1DJPsFeZ8GRi0St90Ke44JjSkmkvKFjq4Q25r6?=
 =?us-ascii?Q?UwUxh3doxCqymYm7RV83bJ8d1nKq2yysPIo1FMN9V3IkKGpU/Zne4C0uRtha?=
 =?us-ascii?Q?l82tIDHQLCQ+ScYOOySRg+4Qjn2U9MNKNQ0xClS/mqjYaYGYBAUfU08F1aPE?=
 =?us-ascii?Q?NxbqeJgHbsCpor3ONMrhAgTJFVhB2gJuTLDuaZyvlTyhlWucv24vSxmg2Ktm?=
 =?us-ascii?Q?E0V5yFfmI4xt8+qOTC5VGJ8Bm0Eb5CovhHpQdnlTtrvotACyk6JLYy4UkLn1?=
 =?us-ascii?Q?+au8wsyM74Z1kwXT3S3RFs1l6WUW6Q+c4IqS7c0rHpA1qTrEWSO47VbYkXVr?=
 =?us-ascii?Q?FKiJWlclwGkXRjatgiSGv3o3ZRDEiAdEByE9SobyURO+zoT/gSUW5HQIVSsp?=
 =?us-ascii?Q?VsxJdXNwncSTMf5Gd9seplbB2XbxDMXuN+LU1LM3ek7rJ0oM7DlEXsxo/062?=
 =?us-ascii?Q?6MLB/1zrLcViGMpShhdgw799jNJKNmI0AkI1I/1rXRdTPLp8pYj5LwUW5pWt?=
 =?us-ascii?Q?17KLWZw3ZXgtnXKc/1x3TxIzeoqWyMNcxZLsv6FwzmqZ1txpyDa40zk53klI?=
 =?us-ascii?Q?AlAcqpamR8pasGQQGgtfKmp69mXI4cAER7lUHi+nozdONvpD46bT532L/JVP?=
 =?us-ascii?Q?JvZMh1fYpYyTQlT/dgnlKx01DiXe7pNQAXMpMiOxZftZy0W0b87rvS7xYDP1?=
 =?us-ascii?Q?2y/TILAnrH/v1JfmXKzet2M8v/wamrpE/l5Eo+Q5bdc8JEy9Y2cT82QBaPBn?=
 =?us-ascii?Q?d2PhbQaTHNFYB3U3dFxd5++SrTJG+orqM/IV98v00Lr2onqKzRc+khRbxqr/?=
 =?us-ascii?Q?r9a+Dm0G4SegjTvOAJazmmgSrH8EAOZ+Ehnps2KBTfG8GawS8M0UYQy45GTq?=
 =?us-ascii?Q?Mcv63G6l8TGr9xyiPkmz4wee8UoGE04ez+TsDUmUUB4dZS5aeD+2TtqSY+lE?=
 =?us-ascii?Q?HLJ2welGLw+6B4zNtyMyWQYJlo4ZSUef2jbXJGIBOfnX0SaM+PRI1GHqi4eM?=
 =?us-ascii?Q?VvXdwpaRLP+iu/ZJloFyBZI=3D?=
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: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd042b15-e788-4e4b-dc86-08d9df9fadbf
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2022 01:11:55.4024
 (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: 8e3zUHYiY8EwySsdyBBS+Zege9A6R69aCW0cnTGTfrYErIJLr7Uw+jwClBsgNCl2uM/fr8DQ4bsBM193FOBBLg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR11MB4262
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: Tuesday, January 25, 2022 1:44 AM
>=20
> On Mon, Jan 24, 2022 at 09:46:26AM +0000, Tian, Kevin wrote:
> > > From: Lu Baolu <baolu.lu@linux.intel.com>
> > > Sent: Monday, January 24, 2022 3:11 PM
> > >
> > > Hi,
> > >
> > > The guest pasid and aux-domain related code are dead code in current
> > > iommu subtree. As we have reached a consensus that all these features
> > > should be based on the new iommufd framework (which is under active
> > > development), the first part of this series removes and cleanups all
> > > the dead code.
> > >
> > > The second part of this series refactors the iommu_domain by moving a=
ll
> > > domain-specific ops from iommu_ops to a new domain_ops. This makes
> an
> > > iommu_domain self-contained and represent the abstraction of an I/O
> > > translation table in the IOMMU subsystem. With different type of
> > > iommu_domain providing different set of ops, it's easier to support m=
ore
> > > types of I/O translation tables.
> >
> > You may want to give more background on this end goal. In general there
> > are four IOPT types in iommufd discussions:
> >
> > 1) The one currently tracked by iommu_domain, with a map/unmap
> semantics
> > 2) The one managed by mm and shared to iommu via sva_bind/unbind ops
> > 3) The one managed by userspace and bound to iommu via iommufd
> (require nesting)
> > 4) The one managed by KVM (e.g. EPT) and shared to iommu via a TBD
> interface
>=20
> Yes, at least from an iommufd perspective I'd like to see one struct
> for all of these types, mainly so we can have a uniform alloc, attach
> and detatch flow for all io page table types.
>=20
> If we want to use the iommu_domain, or make iommu_domain a sub-class
> of a new struct, can be determined as we go along.
>=20
> Regardless, I think this cleanup stands on its own. Moving the ops and
> purging the dead code is clearly the right thing to do.
>=20

Indeed!