[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231206183209.GZ2692119@nvidia.com>
Date: Wed, 6 Dec 2023 14:32:09 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Yi Liu <yi.l.liu@...el.com>
Cc: joro@...tes.org, alex.williamson@...hat.com, kevin.tian@...el.com,
robin.murphy@....com, baolu.lu@...ux.intel.com, cohuck@...hat.com,
eric.auger@...hat.com, nicolinc@...dia.com, kvm@...r.kernel.org,
mjrosato@...ux.ibm.com, chao.p.peng@...ux.intel.com,
yi.y.sun@...ux.intel.com, peterx@...hat.com, jasowang@...hat.com,
shameerali.kolothum.thodi@...wei.com, lulu@...hat.com,
suravee.suthikulpanit@....com, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
zhenzhong.duan@...el.com, joao.m.martins@...cle.com,
xin.zeng@...el.com, yan.y.zhao@...el.com
Subject: Re: [PATCH v6 1/6] iommu: Add cache_invalidate_user op
On Fri, Nov 17, 2023 at 05:07:12AM -0800, Yi Liu wrote:
> +/**
> + * struct iommu_user_data_array - iommu driver specific user space data array
> + * @type: The data type of all the entries in the user buffer array
> + * @uptr: Pointer to the user buffer array for copy_from_user()
> + * @entry_len: The fixed-width length of a entry in the array, in bytes
> + * @entry_num: The number of total entries in the array
> + *
> + * A array having a @entry_num number of @entry_len sized entries, each entry is
> + * user space data, an uAPI defined in include/uapi/linux/iommufd.h where @type
> + * is also defined as enum iommu_xyz_data_type.
> + */
> +struct iommu_user_data_array {
> + unsigned int type;
> + void __user *uptr;
> + size_t entry_len;
> + int entry_num;
These are u32 in the uapi, they should probably be u32 here
too. Otherwise we have to worry about truncation.
> @@ -465,6 +492,9 @@ struct iommu_domain_ops {
> size_t size);
> void (*iotlb_sync)(struct iommu_domain *domain,
> struct iommu_iotlb_gather *iotlb_gather);
> + int (*cache_invalidate_user)(struct iommu_domain *domain,
> + struct iommu_user_data_array *array,
> + u32 *error_code);
Regarding the other conversation I worry a u32 error_code is too small.
Unfortunately there is no obvious place to put something better so if
we reach it we will have to add more error_code space via normal
extension.
Maybe expand this to u64? That is 64 bits of error register data and
the consumer index. It should do for SMMUv3 at least?
Jason
Powered by blists - more mailing lists