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

["Tian, Kevin" <kevin.tian@intel.com>]

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, November 9, 2022 1:30 AM
> 
> On Tue, Nov 08, 2022 at 02:05:20AM +0000, Tian, Kevin wrote:
> > > 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.
> 
> Because it isn't a restriction on allocation, it is a restriction on
> domain attachment. (and this is a bit confusing and subtle, but it is
> what it was built for)
> 
> The purpose is to allow the IOMMU driver to allocate a domain with
> knowledge of what the user would like to do. For instance a small
> allowed range may allow the driver to allocate fewer hops in the IO
> page table, and a create a domain with a smaller aperture.

if a domain can be created with a smaller aperture according to
allowed ranges then the impact is not just on future domain
attachment. a fixed IOVA outside of the allowed ranges will
find error on current domain too.

Should a driver which does this update the reserved ranges too?

> 
> "automatic" is supposed to find a good IOVA that is the best IOVA for
> that mapping. We have defined the best IOVA as one that doesn't reach
> into areas that future domains are allowed to mark as reserved.

'good' or 'best' just implies that the allocation prefers to permitted
ranges over reserved ranges. then when permitted ranges are used
up the allocator can then go to find less-favorable holes outside of
the permitted ranges if not reserved. same as what FIXED IOVA allows.

But the behavior in this uAPI is that automatic IOVAs can be only
in permitted ranges. This is a restriction on allocation instead of
preference.

IMHO I'd like this uAPI clearly defined as either of below:

1) only related to domain attach then automatic IOVA can be allocated
   outside of permitted ranges after the latter are used up;

2) applied to both domain attach and IOVA allocation which then applied
   to both automatic IOVA and fixed IOVA;

> 
> fixed can do anything legal, including violate the allowances if it
> wants. This just means a future domain attachment might fail. Domain's
> won't look at any currently mapped IOVA, only the allowance ranges
> when they size themselves.
> 
> Jason