> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > 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.
