[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DS0PR11MB7529F4D4DABBE29E9B7BF5C9C30CA@DS0PR11MB7529.namprd11.prod.outlook.com>
Date: Mon, 7 Aug 2023 15:08:29 +0000
From: "Liu, Yi L" <yi.l.liu@...el.com>
To: "Tian, Kevin" <kevin.tian@...el.com>,
"joro@...tes.org" <joro@...tes.org>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"jgg@...dia.com" <jgg@...dia.com>,
"robin.murphy@....com" <robin.murphy@....com>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>
CC: "cohuck@...hat.com" <cohuck@...hat.com>,
"eric.auger@...hat.com" <eric.auger@...hat.com>,
"nicolinc@...dia.com" <nicolinc@...dia.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
"chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
"yi.y.sun@...ux.intel.com" <yi.y.sun@...ux.intel.com>,
"peterx@...hat.com" <peterx@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"shameerali.kolothum.thodi@...wei.com"
<shameerali.kolothum.thodi@...wei.com>,
"lulu@...hat.com" <lulu@...hat.com>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"Duan, Zhenzhong" <zhenzhong.duan@...el.com>
Subject: RE: [PATCH v4 09/12] iommu/vt-d: Add iotlb flush for nested domain
> From: Tian, Kevin <kevin.tian@...el.com>
> Sent: Wednesday, August 2, 2023 3:47 PM
>
> Subject: RE: [PATCH v4 09/12] iommu/vt-d: Add iotlb flush for nested domain
>
> > From: Liu, Yi L <yi.l.liu@...el.com>
> > Sent: Monday, July 24, 2023 7:14 PM
> >
> > +static int intel_nested_cache_invalidate_user(struct iommu_domain
> > *domain,
> > + void *user_data)
> > +{
> > + struct iommu_hwpt_vtd_s1_invalidate_desc *req = user_data;
> > + struct iommu_hwpt_vtd_s1_invalidate *inv_info = user_data;
> > + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> > + unsigned int entry_size = inv_info->entry_size;
> > + u64 uptr = inv_info->inv_data_uptr;
> > + u64 nr_uptr = inv_info->entry_nr_uptr;
> > + struct device_domain_info *info;
> > + u32 entry_nr, index;
> > + unsigned long flags;
> > + int ret = 0;
> > +
> > + if (get_user(entry_nr, (uint32_t __user *)u64_to_user_ptr(nr_uptr)))
> > + return -EFAULT;
> > +
> > + for (index = 0; index < entry_nr; index++) {
> > + ret = copy_struct_from_user(req, sizeof(*req),
> > + u64_to_user_ptr(uptr + index *
> > entry_size),
> > + entry_size);
>
> If continuing this direction then the driver should also check minsz etc.
> for struct iommu_hwpt_vtd_s1_invalidate and iommu_hwpt_vtd_s1_invalidate_desc
> since they are uAPI and subject to change.
Then needs to define size in the uapi data structure, and copy size first and
check minsz before going forward. How about the structures for hwpt alloc
like struct iommu_hwpt_vtd_s1? Should check minsz for them as well?
Regards,
Yi Liu
Powered by blists - more mailing lists