On Wed, Apr 03, 2024 at 11:25:35AM +0800, Yi Liu wrote:
> On 2024/4/3 11:04, Baolu Lu wrote:
> > On 3/28/24 8:29 PM, Yi Liu wrote:
> > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > > index 2e925b5eba53..40dd439307e8 100644
> > > --- a/include/linux/iommu.h
> > > +++ b/include/linux/iommu.h
> > > @@ -578,7 +578,8 @@ struct iommu_ops {
> > > struct iommu_page_response *msg);
> > > int (*def_domain_type)(struct device *dev);
> > > - void (*remove_dev_pasid)(struct device *dev, ioasid_t pasid);
> > > + void (*remove_dev_pasid)(struct device *dev, ioasid_t pasid,
> > > + struct iommu_domain *domain);
> >
> > Previously, this callback said "Hey, remove any domain associated with
> > this pasid".
> >
> > Now this callback changes to "Hey, please remove *this* domain from the
> > pasid". What the driver should do if it doesn't match the previously
> > attached domain, or the pasid hasn't been attached to any domain?
>
> I think the caller of this callback should know very well whether
> a pasid has been attached to this domain or not. So the problem
> you described should not happen at all. Otherwise, it is a bug in
> the iommu layer.
>
> Actually, there is similar concern in the iommu_detach_device_pasid().
> The input domain may be different with what iommu layer tracks. If
> so there is a warn. This means the external callers of this API are
> buggy. While, I have more faith on iommu layer. :)
Yeah, the iommu layer should obtain the domain from the pasid xarray
and every driver today also obtains the domain from the pasid
xarray. It is not something different, it is just moving code around.
The core code should guarentee the invariant.
Jason
