> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Tuesday, October 17, 2023 4:52 PM > > On 2023/10/17 02:17, 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? > > this seems like what Jason asks. A type of hwpt can have two kinds > of invalidation data types. Is it really possible? > e.g. vhost-iommu may want its own vendor-agnostic format from previous discussion...
