RE: [PATCH v3 10/15] iommufd: IOCTLs for the io_pagetable

From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	David Woodhouse <dwmw2@infradead.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Joerg Roedel <joro@8bytes.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
	Nathan Chancellor <nathan@kernel.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Shuah Khan <shuah@kernel.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Tom Rix <trix@redhat.com>, Will Deacon <will@kernel.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Chaitanya Kulkarni <chaitanyak@nvidia.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Eric Auger <eric.auger@redhat.com>,
	Eric Farman <farman@linux.ibm.com>,
	Jason Wang <jasowang@redhat.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	"Martins, Joao" <joao.m.martins@oracle.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	"Shameerali Kolothum Thodi"
	<shameerali.kolothum.thodi@huawei.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	Keqian Zhu <zhukeqian1@huawei.com>
Subject: RE: [PATCH v3 10/15] iommufd: IOCTLs for the io_pagetable
Date: Tue, 8 Nov 2022 02:05:20 +0000	[thread overview]
Message-ID: <BN9PR11MB5276706B744018EC6E36E1128C3F9@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <Y2kd/Ptt0iR6SGsh@nvidia.com>

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Monday, November 7, 2022 11:02 PM
> > > + * @allowed_iovas: Pointer to array of struct iommu_iova_range
> > > + *
> > > + * Ensure a range of IOVAs are always available for allocation. If this call
> > > + * succeeds then IOMMU_IOAS_IOVA_RANGES will never return a list of
> > > IOVA ranges
> > > + * that are narrower than the ranges provided here. This call will fail if
> > > + * IOMMU_IOAS_IOVA_RANGES is currently narrower than the given
> ranges.
> > > + *
> > > + * When an IOAS is first created the IOVA_RANGES will be maximally
> sized,
> > > and as
> > > + * devices are attached the IOVA will narrow based on the device
> > > restrictions.
> > > + * When an allowed range is specified any narrowing will be refused, ie
> > > device
> > > + * attachment can fail if the device requires limiting within the allowed
> > > range.
> > > + *
> > > + * Automatic IOVA allocation is also impacted by this call. MAP will only
> > > + * allocate within the allowed IOVAs if they are present.
> >
> > According to iopt_check_iova() FIXED_IOVA can specify an iova which
> > is not in allowed list but in the list of reported IOVA_RANGES. Is it
> > correct or make more sense to have FIXED_IOVA also under guard of
> > the allowed list (if violating then fail the map call)?
> 
> The concept was the allow list only really impacts domain
> attachment. When a user uses FIXED they have to know what they are

it also impacts automatic IOVA

> doing. There is not a good reason to deny the user to use any IOVA
> that is not restricted by the reserved list.
> 

I just didn't get why different restrictions are applied to automatics vs.
fixed allocation.