Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation | Date | Tue, 21 Nov 2023 02:54:15 +0000 |
| |
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Tuesday, November 21, 2023 7:05 AM > > On Mon, Nov 20, 2023 at 08:26:31AM +0000, Tian, Kevin wrote: > > > From: Liu, Yi L <yi.l.liu@intel.com> > > > Sent: Friday, November 17, 2023 9:18 PM > > > > > > This adds the data structure for flushing iotlb for the nested domain > > > allocated with IOMMU_HWPT_DATA_VTD_S1 type. > > > > > > This only supports invalidating IOTLB, but no for device-TLB as device-TLB > > > invalidation will be covered automatically in the IOTLB invalidation if the > > > underlying IOMMU driver has enabled ATS for the affected device. > > > > "no for device-TLB" is misleading. Here just say that cache invalidation > > request applies to both IOTLB and device TLB (if ATS is enabled ...) > > I think we should forward the ATS invalidation from the guest too? > That is what ARM and AMD will have to do, can we keep them all > consistent? > > I understand Intel keeps track of enough stuff to know what the RIDs > are, but is it necessary to make it different? >
probably ask the other way. Now intel-iommu driver always flushes iotlb and device tlb together then is it necessary to separate them in uAPI for no good (except doubled syscalls)? :)
anyway this is driver specific contract. I don't see a need to keep it consistent for all.
| |