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:

quoted

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.

quoted

+ *               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
 

quoted

+ *              <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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel