On Wed, Jan 28, 2026 at 11:29:23AM -0800, Matthew Brost wrote: > On Wed, Jan 28, 2026 at 01:55:31PM -0400, Jason Gunthorpe wrote: > > On Wed, Jan 28, 2026 at 09:46:44AM -0800, Matthew Brost wrote: > > > > > It is intended to fill holes. The input pages come from the > > > migrate_vma_* functions, which can return a sparsely populated array of > > > pages for a region (e.g., it scans a 2M range but only finds several of > > > the 512 pages eligible for migration). As a result, if (!page) is true > > > for many entries. > > > > This is migration?? So something is DMA'ing from A -> B - why put > > holes in the first place? Can you tightly pack the pages in the IOVA? > > > > This could probably could be made to work. I think it would be an > initial pass to figure out the IOVA size then tightly pack.
You don't need to so carefully determine the IOVA size, just allocate the maximum you need which you already have and then tight pack the pages and remember where it ended for the unmap. It should be easier than dummy pages I think, you just have to use a little different math to compute the IOVA. > > This is a possible option to teach things to detect the holes and > > ignore them.. > > Another option — and IMO probably the best one — as it makes potential > usages with holes the simplest at the driver level. Let me look at this > too. It is fairly hard as all the iommu page table implementations work this way. We can add some kind of flag to ignore holes for the new iommupt stuff, but the old stuff doesn't have a fast way to emulate it. Jason
