Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"marcan@marcan.st" <marcan@marcan.st>,
	"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"will@kernel.org" <will@kernel.org>,
	"alyssa@rosenzweig.io" <alyssa@rosenzweig.io>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"zhang.lyra@gmail.com" <zhang.lyra@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	"jon@solid-run.com" <jon@solid-run.com>,
	"jonathanh@nvidia.com" <jonathanh@nvidia.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Nicolin Chen <nicolinc@nvidia.com>,
	"yangyingliang@huawei.com" <yangyingliang@huawei.com>,
	"orsonzhai@gmail.com" <orsonzhai@gmail.com>,
	"gerald.schaefer@linux.ibm.com" <gerald.schaefer@linux.ibm.com>,
	"sven@svenpeter.dev" <sven@svenpeter.dev>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"christophe.jaillet@wanadoo.fr" <christophe.jaillet@wanadoo.fr>,
	"baolin.wang@linux.alibaba.com" <baolin.wang@linux.alibaba.com>,
	"thunder.leizhen@huawei.com" <thunder.leizhen@huawei.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>,
	"robdclark@gmail.com" <robdclark@gmail.com>,
	"asahi@lists.linux.dev" <asahi@lists.linux.dev>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>
Subject: Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group
Date: Fri, 9 Sep 2022 09:07:33 -0300	[thread overview]
Message-ID: <YxsshXKlidq8WgT+@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276D4CDC551DEA5962F9A178C439@BN9PR11MB5276.namprd11.prod.outlook.com>

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

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