On Wed, Oct 18, 2023 at 01:37:20PM -0300, Jason Gunthorpe wrote: > On Mon, Oct 16, 2023 at 11:17:56AM -0700, Nicolin Chen wrote: > > On Mon, Oct 16, 2023 at 08:54:07AM -0300, Jason Gunthorpe wrote: > > > On Mon, Oct 16, 2023 at 11:28:15AM +0800, Yi Liu wrote: > > > > On 2023/10/14 01:56, Nicolin Chen wrote: > > > > > On Fri, Oct 13, 2023 at 11:04:56AM -0300, Jason Gunthorpe wrote: > > > > > > On Fri, Oct 13, 2023 at 12:33:13PM +0800, Yi Liu wrote: > > > > > > > > > > > > > not really. Below the users of the struct iommu_user_data in my current > > > > > > > iommufd_nesting branch. Only the domain_alloc_user op has type as there > > > > > > > can be multiple vendor specific alloc data types. Basically, I'm ok to > > > > > > > make the change you suggested, just not sure if it is good to add type > > > > > > > as it is only needed by one path. > > > > > > > > > > > > I don't think we should ever have an opaque data blob without a type > > > > > > tag.. > > > > > > > > > > I can add those "missing" data types, and then a driver will be > > > > > responsible for sanitizing the type along with the data_len. > > > > > > > > > > I notice that the enum iommu_hwpt_data_type in the posted patch > > > > > is confined to the alloc_user uAPI. Perhaps we should share it > > > > > with invalidate too: > > > > > > > > invalidation path does not need a type field today as the data > > > > type is vendor specific, vendor driver should know the data type > > > > when calls in. > > > > > > I'm not keen on that, what if a driver needs another type in the > > > future? You'd want to make the invalidation data format part of the > > > domain allocation? > > > > The invalidation data has hwpt_id so it's tied to a hwpt and its > > hwpt->domain. Would it be reasonable to have a different type of > > invalidation data for the same type of hwpt? > > Yeah, maybe? Go down the road 10 years and we might have SMMUv3 > invalidation format v1 and v2 or something? > > Like we don't know what the HW side will do, they might extend the > command queue to have bigger commands and negotiate with the driver if > the bigger/smaller format is used. We've done that in our HW a couple > of times now. I see. We'll have the type. Thanks!
