Messages in this thread Patch in this message | | | Date | Fri, 9 Sep 2022 09:07:33 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group |
| |
On Fri, Sep 09, 2022 at 05:00:16AM +0000, Tian, Kevin wrote:
> > I have started this effort by combining this list and the one from > > the side thread: > > > > @@ -266,6 +266,13 @@ struct iommu_ops { > > /** > > * struct iommu_domain_ops - domain specific operations > > * @attach_dev: attach an iommu domain to a device > > + * Rules of its return errno: > > + * ENOMEM - Out of memory > > + * EINVAL - Device and domain are incompatible > > + * EBUSY - Device is attached to a domain and cannot be changed > > With this definition then probably @attach_dev should not return -EBUSY > at all given it's already checked in the start of __iommu_attach_group():
I think the EBUSY would be only for non-conforming drivers. The API semantic is you can always attach a new domain and replace an existing domain.
So things like AMD's "can't do anything but idenitity on RID when PASID enabled" would be -EBUSY.
Seems right that it should be rare though.
> > + * ENODEV - Device or domain is messed up: device is not mapped > > + * to an IOMMU, no domain can attach, and etc. > > if domain is messed up then should return -EINVAL given using another domain > might just work. IMHO here -ENODEV should only cover device specific problems > preventing this device from being attached to by any domain.
Agree > > + * <others> - Same behavior as ENODEV, use is discouraged > didn't get the "Same behavior" part. Does it suggest all other errnos should > be converted to ENODEV?
It says all other errnos should be treated as ENODEV by the caller but forwarded to userspace for further detail.
> btw what about -ENOSPC? It's sane to allocate some resource in the attach > path while the resource might be not available, e.g.:
Seems resaonable that it is similar to ENOMEM
> As discussed in a side thread a note might be added to exempt calling > kAPI outside of the iommu driver.
Sadly, not really.. The driver is responsible to santize this if it is relevant. It is the main downside of this approach.
Jason
| |