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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Nov 09, 2022 at 02:50:34AM +0000, Tian, Kevin wrote:
> > 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?

Not reserved ranges, the domain should have a smaller aperture, and
the checks during domain attachment will refuse if IOVA is to be
mapped out side the domain's aperture.

So if someone mis-uses fixed mode and gets a domain with an aperture
that doesn't cover stuff they mapped then domain attachment will fail.

It is no different from mapping something before domain attachment.

> > "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.

Again, it is not a restriction. It is just how the automatic allocater
works.

> 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;

This makes automatic allocation functionally useless when composed
with allowed ranges. There is no reason to do this.

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

And this is more complicated and slow, without any real purpose.

Jason