From: Liu, Yi L yi.l.liu@intel.com 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...