> From: Tian, Kevin
> Sent: Friday, April 8, 2022 4:06 PM
>
> > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY
> > and
> > IOMMU_CACHE to control the no-snoop blocking behavior of the IOMMU.
> >
> > Currently only Intel and AMD IOMMUs are known to support this
> > feature. They both implement it as an IOPTE bit, that when set, will cause
> > PCIe TLPs to that IOVA with the no-snoop bit set to be treated as though
> > the no-snoop bit was clear.
> >
> > The new API is triggered by calling enforce_cache_coherency() before
> > mapping any IOVA to the domain which globally switches on no-snoop
> > blocking. This allows other implementations that might block no-snoop
> > globally and outside the IOPTE - AMD also documents such a HW capability.
> >
> > Leave AMD out of sync with Intel and have it block no-snoop even for
> > in-kernel users. This can be trivially resolved in a follow up patch.
> >
> > Only VFIO will call this new API.
>
> I still didn't see the point of mandating a caller for a new API (and as
> you pointed out iommufd will call it too).
>
> [...]
> > diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> > index 2f9891cb3d0014..1f930c0c225d94 100644
> > --- a/include/linux/intel-iommu.h
> > +++ b/include/linux/intel-iommu.h
> > @@ -540,6 +540,7 @@ struct dmar_domain {
> > u8 has_iotlb_device: 1;
> > u8 iommu_coherency: 1; /* indicate coherency of
> > iommu access */
> > u8 iommu_snooping: 1; /* indicate snooping control
> > feature */
> > + u8 enforce_no_snoop : 1; /* Create IOPTEs with snoop control */
>
> it reads like no_snoop is the result of the enforcement... Probably
> force_snooping better matches the intention here.
>
Above are just nits. Here is:
Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
