Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
CC:     "Liu, Yi L" <yi.l.liu@intel.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
        "chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
        "yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
        "peterx@redhat.com" <peterx@redhat.com>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "lulu@redhat.com" <lulu@redhat.com>,
        "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
        "Martins, Joao" <joao.m.martins@oracle.com>
Subject: RE: [PATCH v4 05/17] iommufd: Separate kernel-managed HWPT
 alloc/destroy/abort functions
Thread-Topic: [PATCH v4 05/17] iommufd: Separate kernel-managed HWPT
 alloc/destroy/abort functions
Thread-Index: AQHZ7GCN3k0pHsaUpUaqL7OxTm+gurBDfEEAgAMqP4CAAMh40IAAdPYAgARWtXA=
Date:   Mon, 16 Oct 2023 08:26:25 +0000
Message-ID: <BN9PR11MB52763F73D66CBBF6BEBA9B968CD7A@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20230921075138.124099-1-yi.l.liu@intel.com>
 <20230921075138.124099-6-yi.l.liu@intel.com>
 <20231010184932.GT3952@nvidia.com> <20231012190931.GO3952@nvidia.com>
 <BN9PR11MB5276A55B59EAE44DE058DDF58CD2A@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20231013140538.GS3952@nvidia.com>
In-Reply-To: <20231013140538.GS3952@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?5id6hWWzN99ry8/1UDby0pyYsKrF/sQRXVkH3oeZIJjOz2hvF5M8UVTVYyQ6?=
 =?us-ascii?Q?D/xoqztOgCDbCNvrl9GC3SFczX5idqE3AZpSYVW+uUIIDEjp1Z9dZAzpfowI?=
 =?us-ascii?Q?BQnq52kdgcs/Jac6NkbIx5/gE7o0PDx912SC/Ve/gl7MJtAK14Kf1vgHsZ72?=
 =?us-ascii?Q?ebTH46ZpFQLj/ZN5VhQeR11rM7L5T5PvklT6ItJU5ZiBUHeUqCIqw83Tm4Pc?=
 =?us-ascii?Q?mMS7zTtb8Iid1bKUBnkJw1z/R3GAIt0Og4Qv8192i01lde3oTjqnwf+bvBKI?=
 =?us-ascii?Q?ZkbabTq8y/R8+3OtXJVy41Ijly1Ev5I7vaewgo9DIT4c/5cdAoStz4q/kUTG?=
 =?us-ascii?Q?EbLJUXhqzlq7ia2BrnvJLNWM3w8TlTtr1+DNjI13tbjRiIiM18PCmvreZzoa?=
 =?us-ascii?Q?YxJ40daVBbK3BHh88nFSckQyH+lScHymJA+NagwVEaSOGwnLNdXk3NqcOCu6?=
 =?us-ascii?Q?eWeNxN3aX4c99YJpJlqHnR6FUx0mCPLpHXJylexpY9eGZvM/vcrRvcZ2NfAe?=
 =?us-ascii?Q?JYu5i9pQNHtZdx4AHu8Ro+gX4XmjNWLMWpWSBdGNNjrlDCwsKzawliFA6iib?=
 =?us-ascii?Q?Hn9yoZzHGhobsfG8Cj3PaZ+ZXdGLhAxrZt/aM5+3Pist85JwAtXEJ0oTDHV7?=
 =?us-ascii?Q?sVTokPomqY/3vulzSN6VqQDm9Qpr4vZjpKFuhHcY1jIjldQzgSF+akOM4+82?=
 =?us-ascii?Q?9I3oBlY/2THIeNI4CqnEH9TJFAwWRuPasgNradNSrGthNKHITi4Qle84cpXG?=
 =?us-ascii?Q?sbXYSW0KN3cmRywGSjHjfRc1Lj+dJv5SHEQO0eBasGVmFaxB20VDJyvF07Ul?=
 =?us-ascii?Q?vikxyw3SFj6C3FWbmk34BJB2hOIap89Y2yuJ4tT9KJxZA+uyj7C+WTlvhi8S?=
 =?us-ascii?Q?itYOs6GAexAkLdOT4UJt6gk3FpOBR1idv+9uc7guKRGPFEGF0BXIHXrmtjfI?=
 =?us-ascii?Q?aVTZX+HJvzQjIh0ywfgUdMrMMYEr0VM+u3a1fMYS8gFa4G537lZu142g92Rc?=
 =?us-ascii?Q?lTEvgbQ/3Z3oflLOAdsm6N8GIqYObRqJAmC7jsnwxVdUzicKHKXLKgwrNPL1?=
 =?us-ascii?Q?h8D9sYdUXw4Eqk0nylw85kRqeoEOqsF/MSd6WYBwQwK6nRZbnuRFhGK1HHga?=
 =?us-ascii?Q?GU8et0mr1A2ALxvItWEzNS4jVadItL8y90+BeXAFV10uTQud0w2PJ0NQZash?=
 =?us-ascii?Q?oRTIBJVFNe8JUmHJ+U4dbKR0iShmqGQr2l1BPuRjXhGsF6lIX5YqRpaAN4g8?=
 =?us-ascii?Q?liIh/yCendg9XV988WdFNx4wPcQg8yFx4AbL0r9KuOIEFPkjNu+tLs3kqSq+?=
 =?us-ascii?Q?zHq8OeHJx2SsKHXFCmv8+R3yjJlhJ5AP5NNnIfMtK1bT8/tZK2976eHV/3uf?=
 =?us-ascii?Q?/YwhwlYwtkJV8DKMsknQ/gCwt2FlAS7ADsm+2If3aZXXjBHbDBV0hhD7lmZG?=
 =?us-ascii?Q?vZ+Uo+IA1QO8d6qBsBAiZvYLfmeAqUQW81KC9GD5BJoESWvhc8irFD3njRL9?=
 =?us-ascii?Q?4zD3SvI1+kmUjsYLQJrFAqxdjzvYumY7AC6QhjXRT9MelZETvqNOjrCC9U+U?=
 =?us-ascii?Q?dj7VadoL1BHcxlBju7PzvlYi3PwrUhkufy9a0SBz?=
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: 7833c325-8f94-4075-accc-08dbce21963d
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2023 08:26:25.2323
 (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: 0kJy8PmEMnEBAxHNObCEmOjB43tCE2vAYm6NTQ/cj1+YpqwejrJ3N55v7xGsKUrxFqwYhdcvnevZLmga8gv02g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB8207
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Mon, 16 Oct 2023 01:26:46 -0700 (PDT)

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, October 13, 2023 10:06 PM
>=20
> On Fri, Oct 13, 2023 at 07:13:34AM +0000, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > Sent: Friday, October 13, 2023 3:10 AM
> > >
> > > Also, we probably should feed enforce_cache_coherency through the
> > > alloc_hwpt uapi and not try to autodetect it..
> > >
> >
> > In the past we had a long discussion about this with the conclusion
> > that user opt is the ideal model but it's fine to stay with autodetect
> > and existing vfio/kvm contract for coherency detection until we
> > see a real demand for user opt.
> >
> > Is there anything new which changes your mind to have user opt now?
>=20
> I guess, I was just looking at the complexity it brings to keep that
> working.
>=20

vfio_file_enforced_coherent() currently just looks at device_iommu_capable(=
)
and can be called before attach, assuming an autodetect model.=20

moving away from autodetect would need a new contract which I hesitate
to bother with at this point.