On Wed, Nov 09, 2022 at 02:50:34AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > 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
