On Wed, May 24, 2023 at 05:03:37AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@xxxxxxxxxx>
> > Sent: Saturday, May 20, 2023 2:49 AM
> >
> > On Fri, May 19, 2023 at 08:51:21AM +0000, Tian, Kevin wrote:
> >
> > > > @@ -346,6 +350,10 @@ struct iommu_ops {
> > > > * @iotlb_sync_map: Sync mappings created recently using @map to the
> > > > hardware
> > > > * @iotlb_sync: Flush all queued ranges from the hardware TLBs and
> > empty
> > > > flush
> > > > * queue
> > > > + * @cache_invalidate_user: Flush hardware TLBs caching user space IO
> > > > mappings
> > > > + * @cache_invalidate_user_data_len: Defined length of input user data
> > for
> > > > the
> > > > + * cache_invalidate_user op, being sizeof the
> > > > + * structure in include/uapi/linux/iommufd.h
> > >
> > > same as comment to last patch, can this be merged with @hw_info?
> >
> > I think it's better to keep them separate, since this is added
> > in struct iommu_domain_ops, given it is domain/hwpt specific,
> > while the hw_info is in struct iommu_ops?
> >
>
> Just be curious whether there are real examples in which the data
> len might be different upon the hwpt type...
Likely "no" on top of my head. Yet it's a bit odd to see the
data length for cache_invalidate_user being added along with
the hw_info, since they belong to two different structs, and
even two different series?
Thanks
Nic
