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