> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, May 3, 2023 2:12 AM > > On Sat, Apr 29, 2023 at 12:07:24AM +0800, Yi Liu wrote: > > > The emulated stuff is for mdev only, it should not be confused with > > > no-iommu > > > > hmmm. I guess the confusion is due to the reuse of > > vfio_iommufd_emulated_bind(). > > This is probabl y not a good direction I see. But if not reusing, then there may be a few code duplications. I'm fine to add separate _bind/unbind() functions for noiommu devices if Alex and you prefer it. > > > Eg if you had a no_iommu_access value to store the access it would be > > > fine and could serve as the 'this is no_iommu' flag > > > > So this no_iommu_access shall be created per iommufd bind, and call the > > iommufd_access_create() with iommufd_access_ops. is it? If so, this is > > not 100% the same with no_iommu flag as this flag is static after device > > registration. > > Something like that, yes > > I don't think it is any real difference with the current flag, both > are determined at the first ioctl when the iommufd is presented and > both would state permanently until the fd close Well, noiommu flag would be static from registration till unregistration.:-) While no_iommu_access's life circle is between the bind and fd close. But given that the major usage of it is during the duration between fd is bound to iommufd and closed, so it's still possible to let no_iommu_access serve as noiommu flag. 😊 Regards, Yi Liu
